Perspectives

Why “Yes” Doesn’t Scale

Everyone loves a “can do” attitude. “Yes, we can!” has become – even when stripped of any political connotations – the rallying call of an entire generation, empowered, driven, and enthusiastic. For a young startup, this type of optimism is a prerequisite. Pessimists would probably never embark on a dangerous journey into uncharted waters, let alone survive the trials and tribulations that are an integral part of bringing a new product to market. But as startups grow, rampant positivity won’t always serve you well.

Starting with Yes: The Customer-Centric Mindset

In a company’s early days, the prevailing operating mindset is customer-centric. In the relentless pursuit of product-market fit, there’s no other way but to let your customers (existing and potential) dictate where you should be heading. At this stage, when the company is still small, the people talking to customers are close to all aspect of the product, and it’s still possible to talk to every single customer.

This mindset conditions the organization to meet customer needs, fulfill their requests and be responsive. This approach often results in reactive behaviors: features that get developed may be targeted to individual customers’ needs, and you might even see language used in the app that reflects a particular customer’s vernacular. At this stage, you typically see frequent releases, as the company pushed to improve product-market fit and increase adoption.

This focus is very helpful and appropriate in a company’s infancy, but it also has its risks and downsides: It is easy to slip into an “order taker” attitude (some have referred to it as McDonald’s drive-through product management) where the main goal becomes saying “yes” to every request and fulfilling every customer order as it comes in. Additionally, since every customer cares solely about their own specific needs, the product is at risk of becoming a Frankenstein of non-cohesive features patched together.

Too Big to Yes

Hopefully, when product-market fit is achieved, a company will move into the exciting and long-awaited period of scaling. But growth brings pain, and when your customer base grows, it also becomes less manageable. Earlier on, it may have been feasible to talk to every customer frequently,  build relationships, and keep a close finger on the pulse of what the customer needs are. With the growing base, however, this may no longer be practical. With greater support ticket volume, your support organization will start feeling pressured, and product people will start to drift away from their customer-focused mindset.

It’s never a good idea to say yes to every customer request, but when your company was small you may have been doing that. At this stage, though, it simply doesn’t scale anymore. Now, it seems unavoidable to shift away from your previously customer-centric mindset to a product-centric one.

The Product-Centric Mindset

Does this mean that the organization won’t focus on customer needs any more? Hardly. The product-centric mindset aims to build a well-designed, high-quality product, always with the goal of satisfying the needs of the target market and the key persona(s) using the product. While the customer-centric mindset tends to be more reactive to individual needs and requests rooted in the present, the product-centric mindset tends to be more proactive and build for the future, guided by the product strategy and roadmap.

Instead of meeting very specific needs of individual (or a small number of) customers, the product-oriented approach often results in a broader functional design to meet a variety of needs. Resulting features may therefore satisfy the majority of, but not all specific, needs in favor of broader appeal. In order for a feature to be considered and prioritized, the product organization will have had to hear from several (sometimes many) customers about similar needs. They will then abstract specific requirements in order to arrive at a more general implementation and feature set. This approach is quite different from the quick turnaround of the reactive customer-centric one, and often produces a more thought-out and cohesive product. Instead of smaller, independent enhancements that get released frequently, the product-centric approach tends to focus on larger features that get released less frequently.

Since the product-centric mindset tends to drive a more methodical approach, one is more likely to find user research, usability testing, product councils, and focus groups in the respective organizations. At the same time, the growth of the product function also necessitates a higher degree of planning and coordination across product owners, and roles related to UI and UX design often get staffed by dedicated specialists.

Overall, the product-centric mindset is not about focusing away from the customer and on the product for the sake of product alone, but about methodical product management as a craft with a goal of making the best product for the overall market, not just fulfilling every single small enhancement request as it comes in.

Abandoning the Swiss Army Knife

Yes, a product-centric mindset requires saying no. But it has a number of advantages, including an increased focus on how to take the product to the next level, reduced WIP, functional consistency, and better design and quality. Trying to say “yes” to everything when you’re rapidly-growing would be like dying of a 1,000 paper cuts. Instead of building a Swiss army knife that is not really good at any one thing, you should focus on creating a product that’s truly great at (probably fewer) key things, those which are part of its core value proposition and really matter to your target market and personas.

As difficult and counter-intuitive as it may seem, saying “no” to the majority of things might be the best thing one can do at this point. Just because you can, doesn’t mean you should.

People think focus means saying yes to the thing you’ve got to focus on. But that’s not what it means at all. It means saying no to the hundred other good ideas that there are. You have to pick carefully. […] Innovation is saying ‘no’ to 1,000 things.” Steve Jobs

The School of No

So what filters could we apply when evaluating new ideas and requests in practice to make sure we say “yes” to the few key things that really matter?

Consider asking the following:

Does this feature:

  • Benefit our main target market segment?
  • Align with our target persona(s)?
  • Lie within our product’s core feature set and value prop? If not, is there agreement that extending into this area is desirable and now is the right time for it?
  • Align with our overall, 6-12 month product roadmap? If not, is the roadmap in need of adjustment?

What percentage of our user base will benefit?

  • Have we heard from a significant number of our users/customer base about this feature?

Have we validated that:

  • The problem is worth solving?
  • Our solution is resonating with a significant number of our users/customers? Are we able to solve it really well or only mediocre?
  • Our solution is technically feasible and can be achieved in a reasonable period of time?
  • We can monetize this feature or that it will have significant impact on new customer acquisition or retention?

In order to say “yes” to this new work item, what will we say “no” to and replace on our roadmap?

I have also found that Scaled Agile’s WSJF (“weighted smallest job first”) method results in good conversations and can help assign the proper priority to work items.

Goodbye to All That Yes

In the long-term, I believe that the product-centric mindset better serves an organization, as long as it is understood correctly. A growing organization needs clear focus and won’t be able to scale “Yes, we can!” when faced with the endless array of ideas and requests pouring in. Instead, it will benefit from clearly saying “yes” to only the few things that will help move the organization forward while saying “no” (or at least “not yet”) to all others.

About the Author

René is a Product Strategist for Agile Transformation, a growing SaaS start-up. He is a is self-professed product geek, Agilist, developer, blogger, and thinker. He is passionate about creating high-quality products users love. His background includes roles in development, consulting, project management and enterprise agility, most recently at Cox Automotive.