Product strategy implies the answer - “No!”

Translation of the original article by Des Traynor

If you are creating a product, you should be perfectly able to say no. Not “may be” or “later,” namely, not. During the creation of a product, it is not necessary to include in it options that can theoretically benefit, but are indirectly related to it, because it will prevent accurate determination of the parameters of the product and its focus.


')
As follows from the latest advertising Apple, there may be tens of thousands of versions of your product, which may appear due to different features, important and unimportant. Most of these versions fail miserably and only the best will be able to serve the market.

So many reasons to say yes.

When you are in the process of creating a product, you will be overwhelmed with good ideas. They will come from your customers, colleagues and yourself. You will have a lot of reasons to tell them yes, because they are good. Here are 12 arguments in the style of Don Lindsey , which often help unnecessary features get into the product.

But the statistics look great.

Interface improvements over time

“We tried this feature with a small group of testers and the improvements are clearly visible on the graph . ” Often this approach suffers from selective analysis of statistics. The product is a complex system. Even if the statistics are good and the data is stable, you still need to think about what your product is, what it is for. Add Tetris to your product and maybe you will also see improvements, but will your product get better from this?

But it only takes a few minutes.

Calculated time to develop a little feature.
Real time to develop a little feature

In fact, work time should never be a reason to add something to a project. Yes, it may be worth adding it to the plan, and thinking about it later, but not trying to do everything now.

A lot of bad ideas can be translated into a product very quickly. Do not be tempted. There are no small changes. By the way, even a small change can complicate a product, and its simplification is not invested in these “ only 5 minutes ”.

But this client may leave

This is chantage. None of the customers can be more important than a good product. This road will lead to the creation of an ideal product for one of your clients, because you did what he said. If you overestimate a single client, then underestimate everyone else.

But we can make it optional.

This leads to death from the settings. Optional features hide the complexity of the main screen of the application, but this complexity begins to come out in all its other places. The apparent price of this is a disgusting interface with a whole bunch of conditional design and tons of settings. Hidden price is expressed in the loss of the focus of your product. Your product becomes “an organizer who seems to be able to send you bills and coordinate payments, but he doesn’t seem to be reporting on current events, I don’t know, I’m not sure ”.

But my cousin's neighbor said ...

Looks like a joke. This is common in SaaS companies that cannot understand what kind of work they are doing. Extrapolating a tiny sample is a sure way to years of testing, research, generating statistics and behavior. Saying “my brother's company uses Google Analytics, and it uses extended segments” can lead to the use of extended segments, bypassing the questions: what is it? What does your product do? Is this brother's company good at choosing customers? Do they really use it or just say so? Does this technique suit you?

But we have nothing planned

Unoccupied hands looking for work. Many, seeing idle developers coming up with new features, if only they worked. The adoption of ideas is accelerating - everything, just to avoid idleness. This is not the best way to improve your product.

Instead of developers getting a little extra time, they lose it. All those who work as developers know: “If you have time for laziness, then you have time to clean the code”. Leisure time is ideal for editing bugs, cleaning test cases, refactoring. Do not just keep the team working.

But I thought we would work on what we wanted.

This argument has become a classic. Many large companies promise developers that they will work on what they want and sell it. There are two interchanges:

1. This is a lie told to attract developers. It very quickly becomes apparent and fails.
2. This is true, and its final result is a completely unused product and half-completed ideas.

There is a difference between the developer’s proposal to work on things in the normal way (good) and the proposal of embedding unplanned features in the product (badly).

But 713 thousand people want it

Try to avoid situations where someone is trying to justify the raw numbers. Any, even the least developed product will find its number of consumers. For example: “We can fill Doloresky Park with people who have asked for integration with Excel”. It makes you turn away from the original course and succumb to the influence of the crowd, to become “one of them”. Can you really say no so cruelly?

And you should. Otherwise, most of your customers may suffer. The question is not, “can we fill Doloresky Park with people who need this feature,” but, “is it valuable in the product of our focus, will buyers use it?”

But our competitors have it.

This does not mean that it is a good idea. It may be that they are just testing a new technology. This idea may not be so brilliant. Maybe they are already planning to remove this from the application. It is a mistake to believe that your competitors are smarter and more perspicacious than you. Obsession with competitors' ideas can put you down so that you will be able to show yesterday's technology only tomorrow.

But if we don't do it, someone else will.

This does not mean that it should be in your product. If someone else does this, will customers abandon your product? Will they switch to the other side? Just saying “someone else will do” is good, but means nothing. I noticed that I say this very often. This logic is used to expand the product, because you do not want to stop there for a second. You are afraid to reach the finish of your project.

Here is an example: a typical date includes a movie, dinner and a trip home. If the owner of the cinema was constantly worried about what other businessmen would do and would like to get more benefits, he would have placed the restaurant in his cinema and would have created a company of bringing people to their homes a la taxi. And all these three services would be disgusting. And then more restaurants would start showing films ...

But the boss wants it

So accurately, quickly make pie charts. Tons of them.

If the boss is also a product manager and he has time to make smart holistic decisions, then everything is fine. But if someone tries only to earn points in the eyes of others, it will lead to trouble.

But it will be what will change our product.

A product change makes you think well about what to do. You can talk to everyone about any change and say that it will definitely change the product, but these are just fairy tales. When you are afraid to make serious decisions, you begin to believe that "here, this is it, that very thing." You will end up with a set of ideas and a repository of their implementations, but not with a finished product.

Why is no so important?

The fact is that no one plans failure. Defining and clipping them is quite simple. But decisions made when working on a serious product are not so simple. They make you read the entire description of the feature and its implementation and say: “This is a really good idea, I understand why our customers will like it. Great job. But we will not add it to the product ... That's what we will do instead. ”

From the translator: the article gives a number of reasons why you need to be able to say “no”, with good examples and exposing fakaps. In essence, how to avoid provocation from one side or the other. At the same time, the author did not say the main thing - which allows us to say the cherished "yes." Two points: first, I recommend reading this article ; secondly, my position is as follows: you need to be able to relate the proposed feature to the strategy of the product as a whole. If the feature does not help in achieving the strategic goal - in the cold. Otherwise, it is pure "ficherism". We do not know who our users are or what they need, so we will do everything just in case - a universal combine for all occasions. This is a dead end road. I hope that in the near future I will find time to summarize my experience as a product manager of Yandex and write a detailed article on this topic.

The translation was made as part of the Tolstoy Summer Camp and MetaBeta summer start-up school.