PRODUCT STRATEGY MEANS SAYING NO
PRODUCT STRATEGY MEANS SAYING NO
AUTHOR Des Traynor
Co-founder @intercom.
If you’re building a product, you have to be great at saying no. Not “maybe” or “later”. The only word is no.
Building a great product isn’t about creating tons of tactically useful features which are tangentially related. It’s about delivering a cohesive[粘性的；有结合性的；有粘聚性的常用释义分布图] product with well defined parameters.[mothlee:一句话指出了新手的误区。]
As Apple’s latest advert points out, there are literally tens of thousands of permutations[置换] of your product based on every addition, both minor and major. Most of these variations will flop[<口>失败]. Only a select few will properly serve the market.
SO MANY REASONS TO SAY YES
When your product gets traction, you’ll find yourself inundated[洪泛的] with good ideas for features. These will come from your customers, your colleagues, and yourself. Because they’re good ideas, there’ll always be lots of reasons to say yes to them. Here’s 12 arguments in the style of Don Lindsay that are commonly used to sneak features into a product:
1. BUT THE DATA LOOKS GOOD
“We’ve tried this feature with a small group and engagement is off the charts.” Often this approach suffers from selective data analysis. Products are complex systems. What appears to be an increase in engagement is really just pushing numbers around from place to place. Even if the data is solid, and the increase in engagement is good, you still have to question whether it fits within the purview of the product. Add Tetris[俄罗斯方块] to your product and you’ll probably see a boost in engagement, but does that mean your product is better?
2. BUT IT’LL ONLY TAKE A FEW MINUTES
The main problem with this argument is that the scope of work should never be a reason to include a feature in a product. Maybe it’s a reason to bump it up the roadmap, but that’s a roadmap decision, not a product one.
Lots of bad ideas can be built quickly. Don’t be seduced[引诱；怂恿；勾引]. There are no small changes. Also, even the tiniest additions add hidden complexity that isn’t accounted for in the “but it’s just 5 minutes” estimate.
3. BUT THIS CUSTOMER IS ABOUT TO QUIT
This is feature blackmail. No customer can be more important than a good product. The road to consulting-ware is signposted[有路标的] just this once for just this customer. It leads to the perfect product, for just one customer, provided you keep doing what they say. Delivering extra value to one customer comes at the cost of taking value away from many others.
4. BUT WE CAN JUST MAKE IT OPTIONAL
This leads to death by preferences. Making features optional hides the complexity from the default screens in the interface, but it still surfaces everywhere else. The visible cost of this is a messy interface with lots of conditional design and heaps of configuration. The hidden cost is that every optional feature weakens your product definition. You become “a time tracker that can also send invoices and, sorta, do payment reconciliation, but not reporting, yet, I think, I don’t know.”
5. BUT MY COUSIN’S NEIGHBOUR SAID…
This is the “appeal to the anecdote”. It is rife[流行的] in consumer products, or in a SaaS company that can’t decide what precise jobs they do. Extrapolating from a tiny sample is an easy way to by-pass years of experience, research, data, and behaviour to make a statement that sounds reasonable. Saying “my brother’s company use Google analytics, they all use advanced segments” is an easy way to make a case for advanced segments, bypassing the question of what your product actually does, whether your brother’s company are a good target customer, whether they actually use it or just say they do, and whether advanced segments are actually the right solution for what your customers are trying to do.
6. BUT WE’VE NOTHING ELSE PLANNED
The devil makes work for idle[懒惰的] hands. The problem here is that someone sees one or more engineers sitting idle and immediately rushes through a new feature to “keep em busy“. Decisions are rushed and designs are cobbled[粗制滥造] together all in the name of avoiding idle time. This is a bad way to “improve” a product.
Instead of adding to technical debt here, there’s an opportunity to pay some off. As anyone who has worked in a kitchen knows: “if you’ve time to lean, you’ve time to clean.” Idle time is best used fixing bugs, cleaning up test suites, refactoring, etc. rather than derailing a product vision just to “keep the team productive”.
7. BUT WE’RE SUPPOSED TO BE ALLOWED WORK ON WHATEVER WE WANT
This argument appeals to cultural pride. There are many big name companies that promise engineers they can build whatever they want and ship it. Usually this promise has one of two outcomes:
- It’s a lie told to attract engineers. This gets noticed quickly and falls apart. You can’t fake culture.
- It’s true, and the end result is a one-size-fits-none product full of half baked ideas. There’s a difference between encouraging engineers to build things internally (a good thing) and letting people add features to a product bypassing product management(a bad thing).
8. BUT 713,000 PEOPLE WANT IT
Always beware when someone falls back to raw numbers to justify something. Any product with any amount of traction can make an emotive claim using numbers. E.g. “You could fill Dolores Park with people who have asked for Excel integration“. Such a claim forces you to take off your product design hat, and be one of the “people”. Are you really going to say no to all those faces?
You have to. Because the majority of your users will suffer otherwise. The question isn’t “could we fill Dolores park with people who want this feature?”, it’s “is this a valuable feature, within our purview, that all our customers will use?”
9. BUT OUR COMPETITORS ALREADY HAVE IT
That doesn’t mean it’s a good idea. It could be something they’re trying out. It could be a shit idea. It could be something they’re planning on killing. It’s a mistake to assume that your competitors are in any way smarter or more tactical than you. Obsessing about your competitor’s features relegates you to permanently deliver yesterday’s technology tomorrow.
10. BUT IF WE DON’T BUILD IT SOMEONE ELSE WILL
That doesn’t mean it should be in your product. If someone else builds it, do customers no longer need your product? Will they all switch over? Simply saying “someone else will” sounds good, but means nothing. I’ve caught myself saying it many a time. Often this is the logic used to expand a product because you’re not willing to admit your product stops somewhere. You’re afraid to draw the line.
Here’s an example: A typical date might involve a movie, dinner, and a lift home. If a cinema owner is constantly worried about what other businesses will build, and hungry to capture more value, they’ll put a restaurant into their cinema and start a cab company. Then they’ll be shit at all three. Then restaurants start screening movies…
11. BUT THE BOSS REALLY WANTS IT
If the boss is also the product manager, and has the necessary time and insight to make smart holistic decisions, then this is fine. However, if someone is trying to earn brownie points by focusing on pet projects that their manager has a penchant for, this leads to trouble.
12. BUT THIS COULD BE ‘THE ONE’
This is a classic “Appeal to the Unknown”. Editing a product requires some hard decisions about what to build. You can speculate that any unbuilt feature could transform your product. But speculation[推测；投机；沉思] is all it is, nothing more. When you’re afraid to make hard decisions, you fall back on appealing to the unknown, and therefore building everything. You end up with a repository of features, not a product.
WHY IS ‘NO’ IMPORTANT?
The thing is, no one keeps crap ideas in their roadmap. Identifying and eliminating[除去；剔除；忽略；淘汰] the bad ideas is the easy bit. Real product decisions aren’t easy. They require you to look at a proposal and say “This is a really great idea, I can see why our customers would like it. Well done. But we’re not going to build it. Instead, here’s what we’re doing.”.
Follow up posts:
1. Rarely say yes to feature requests
2. Product strategy in 7 minutes
3. What does feature creep look like?
Want to read even more of our product management best practices? Download our free book, Intercom on Product Management. It’s recommended by folks like Ryan Singer, Hunter Walk, and Dharmesh Shah.