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.
As Apple $AAPL’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.
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 are 12 arguments in the style of Don Lindsay that are commonly used to sneak features into a product:
“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?
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.
This is feature blackmail. No customer can be more important than a good product. The road to consultingware 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.
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.”
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 bypass years of experience, research, data, and behavior to make a statement that sounds reasonable. Saying “My brother’s company use Google $GOOGL 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 is 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.
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’s 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.”
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:
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).
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: “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?”
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.
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. They’ll then be shit at all three. Then restaurants start screening movies…
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 his manager has a penchant for, this leads to trouble.
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.
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.”
