Product strategy implies the answer is "No!"
original article authored by Des Traynor
If you create a product, you should perfectly be able to say “no”. Not “maybe” or “later”, namely no. During the creation of the product does not need to include options that could theoretically benefit, but to it have an indirect relationship, because it will prevent accurately determine the parameters of the product and its focus.
It follows from the last Apple, there may be tens of thousands of versions of your product that can occur due to different features, important and unimportant. Most of these versions fail miserably and only the best can serve market.
When you are in the process of product creation, you will be inundated 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's 12 arguments in the style of don Lindsay, which often help unnecessary features to get in the product.
“We tested this feature with a small group of testers and improve well-marked on the chart”. Often this approach suffers from sampling statistics. The product is a complex system. Even if the statistics are good, but data is stable, you should still think about what represents your product, for which it is intended. Add Tetris to your product and maybe you will also see improvements, but will your product better?
Calculated time development of small features
In fact, time should never be a reason for adding anything to the project. Yeah, maybe I should add it in the plan, and to consider later, but not strive to do everything now.
So many bad ideas can be embodied in the product very quickly. Don't be offended. there are No small changes. by the Way, even a small change can complicate the product and its simplification is not embedded in these “only 5 minutes”.
It's blackmail. None of the clients could not be more important than a good product. This road will lead to the creation of the perfect product for one of your customers, because you did what he said. If you overestimate one customer means underestimate everyone else.
This leads to death by preferences. Optional features hide the complexity of the main app screen, but this complexity begins to emerge in all other places. The visible price of this is a disgusting interface with lots of conditional design and tons of settings. Hidden price is reflected in the loss sharply focused your product. Your product becomes “organiser which seems to be able to send you invoices and coordinate payments, but he still seems not to reports on current events, I don't know”.
Like the anecdote. This is common in SaaS companies that can't understand what kind of work they do. Extrapolating from a tiny sample – a sure way to years of testing, research, development and statistics behavior. Saying “my brother's company use Google Analytics and used advanced segments” may result in use of advanced segments, bypassing the questions: what is it? what your product does? whether or not the company this brother is good in choosing clients? whether they use it or are you just saying that? the suitability of this method?
Unoccupied hands looking for work. Many, seeing lounging developers coming up with new features, if only they worked. The adoption of ideas is accelerating – all, if only to avoid idleness. It's not the best way to improve your product.
Instead, the developers got a little extra time, they lose it. All who work for developers know: “If you have time for lazy, means you have time to clean the code.” Free time is ideal for correcting bugs, cleaning, test cases, refactoring. Not worth it just to keep the team in the work.
This argument has become a classic. Many large companies promise to developers that they will be working on what you wish to sell it. There are two connections:
There is a difference between the supply developer to work on things in the normal order (good) and offer integrated product unplanned features (bad).
Try to avoid situations when someone is trying to justify the raw numbers. Any, even the slightest of the developed product will find its consumers. For example: “We can fill Dolorese Park people who asked for integration with Excel.” It makes you collapse with an initial course and be influenced by the crowd, to become “one of them”. Did you so cruel to say no?
And you have to. Otherwise, most of your customers can suffer. The question is not, “can we fill Dolorese Park with people who need this feature?” but rather, “is it valuable in the product of our focus will be is it available to buyers?”
This does not mean that it is a good idea. Could be that they just test new technology. This idea may not be brilliant. Maybe they are already planning to remove it from the app. It is a mistake to assume that your competitors are smarter and more perspicacious than you. The obsession with ideas of competitors can lower you so that you will show yesterday's technology tomorrow.
This does not mean that it should be in your product. If someone else will do it, throw customers your product? Will it turn to the other side? Just say “someone else will do” is good, but means nothing. I noticed that they say it very often. This logic is used for product expansion, because you don't want to stop there for a second. Are you afraid of blocks your project.
Here's an example: typical date includes a movie, dinner and a ride home. If the owner of the theater was constantly worried about what will make other businesses would like to gain more, he would put a restaurant in a movie theater and would create a company deliver people home a la taxi. And all three of these services would be disgusting. And then the restaurants started to show films...
If the boss is also the product Manager and he has time to make smart holistic decisions, then everything is fine. But if someone tries only to score points in the eyes of others, it will lead to trouble.
Changing product forces you to think about what to do. You can tell everyone about any change and say that it will necessarily change the product, but it is just stories. When you are afraid to make serious decisions, you start to believe that “that's just it, the most”. You're finished with a set of ideas and a repository implementations, but not with the finished product.
The fact that no one plans to fail. Identifying and clipping the add is quite simple. But the decisions taken while working on a major product is not so simple. They make you read the full description, features and its implementation and say, “This is a really good idea, I understand why it will appeal to our customers. Great job. But we will not add it to the product... That's what we'll do instead.”
From the translator: the article gives a number of reasons why you need to be able to say "no", with illustrative examples and expose fakapov. In fact — how to avoid the provocations from one side or another. At the same time, the author said the main thing — it allows us to say the coveted "Yes". Two things: first, I recommend to read this article; secondly, my position is that we need to be able to correlate the proposed feature with the strategy of the product in General. If a feature does not help in achieving the strategic goal of the frost. Otherwise this is pure "feceris". We don't know who our users are and what they need, so we in any case will make all — the versatile harvester for all occasions. It's a dead end road. I hope that in the near future will find time to summarize my experience a product Manager of Yandex and to write a detailed article on this topic.
The translation is done in the framework of the summer school start-UPS Tolstoy Summer Camp and MetaBeta.
Article based on information from habrahabr.ru
If you create a product, you should perfectly be able to say “no”. Not “maybe” or “later”, namely no. During the creation of the product does not need to include options that could theoretically benefit, but to it have an indirect relationship, because it will prevent accurately determine the parameters of the product and its focus.
It follows from the last Apple, there may be tens of thousands of versions of your product that can occur due to different features, important and unimportant. Most of these versions fail miserably and only the best can serve market.
there are So many reasons to say Yes
When you are in the process of product creation, you will be inundated 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's 12 arguments in the style of don Lindsay, which often help unnecessary features to get in the product.
statistics But looks great
interface Improvements over time
“We tested this feature with a small group of testers and improve well-marked on the chart”. Often this approach suffers from sampling statistics. The product is a complex system. Even if the statistics are good, but data is stable, you should still think about what represents your product, for which it is intended. Add Tetris to your product and maybe you will also see improvements, but will your product better?
But it only takes a few minutes
Calculated time development of small features
Real-time development small features
In fact, time should never be a reason for adding anything to the project. Yeah, maybe I should add it in the plan, and to consider later, but not strive to do everything now.
So many bad ideas can be embodied in the product very quickly. Don't be offended. there are No small changes. by the Way, even a small change can complicate the product and its simplification is not embedded in these “only 5 minutes”.
But the client can go
Translation
How to make terrible software: 1. To promise the client to embed it in a one-time feature in project 2. To fulfill the promise 3. To repeat
It's blackmail. None of the clients could not be more important than a good product. This road will lead to the creation of the perfect product for one of your customers, because you did what he said. If you overestimate one customer means underestimate everyone else.
But we can make it optional
This leads to death by preferences. Optional features hide the complexity of the main app screen, but this complexity begins to emerge in all other places. The visible price of this is a disgusting interface with lots of conditional design and tons of settings. Hidden price is reflected in the loss sharply focused your product. Your product becomes “organiser which seems to be able to send you invoices and coordinate payments, but he still seems not to reports on current events, I don't know”.
But a neighbor of my cousin said...
Translation
Team a week ago, I spoke with a cousin of a neighbor of my sister. It is exactly our target audience (25 years, female, have a PhD). She said that all her friends are actively using hash tags.
I declare an unscheduled meeting tomorrow at 8 am. Kandy (that's her name) will join our conference.
#Thanks #Team
End of communication
CEO
I declare an unscheduled meeting tomorrow at 8 am. Kandy (that's her name) will join our conference.
#Thanks #Team
End of communication
CEO
Like the anecdote. This is common in SaaS companies that can't understand what kind of work they do. Extrapolating from a tiny sample – a sure way to years of testing, research, development and statistics behavior. Saying “my brother's company use Google Analytics and used advanced segments” may result in use of advanced segments, bypassing the questions: what is it? what your product does? whether or not the company this brother is good in choosing clients? whether they use it or are you just saying that? the suitability of this method?
But we have nothing scheduled
Unoccupied hands looking for work. Many, seeing lounging developers coming up with new features, if only they worked. The adoption of ideas is accelerating – all, if only to avoid idleness. It's not the best way to improve your product.
Instead, the developers got a little extra time, they lose it. All who work for developers know: “If you have time for lazy, means you have time to clean the code.” Free time is ideal for correcting bugs, cleaning, test cases, refactoring. Not worth it just to keep the team in the work.
But I thought we were going to work on what you want
This argument has become a classic. Many large companies promise to developers that they will be working on what you wish to sell it. There are two connections:
-
the
- that's a lie, it is said to attract developers. It very quickly becomes apparent and fails. the
- It is the truth and its ultimate result is fully implemented nobody would want a product half done.
There is a difference between the supply developer to work on things in the normal order (good) and offer integrated product unplanned features (bad).
But 713 thousand people want it
Try to avoid situations when someone is trying to justify the raw numbers. Any, even the slightest of the developed product will find its consumers. For example: “We can fill Dolorese Park people who asked for integration with Excel.” It makes you collapse with an initial course and be influenced by the crowd, to become “one of them”. Did you so cruel to say no?
And you have to. Otherwise, most of your customers can suffer. The question is not, “can we fill Dolorese Park with people who need this feature?” but rather, “is it valuable in the product of our focus will be is it available to buyers?”
But our competitors are
Translation
You look at competitors and think “We need to copy all of them!”. They look at your application and think: “Half of it should be removed”.
This does not mean that it is a good idea. Could be that they just test new technology. This idea may not be brilliant. Maybe they are already planning to remove it from the app. It is a mistake to assume that your competitors are smarter and more perspicacious than you. The obsession with ideas of competitors can lower you so that you will show yesterday's technology tomorrow.
But if we do not do this, it will make someone else
This does not mean that it should be in your product. If someone else will do it, throw customers your product? Will it turn to the other side? Just say “someone else will do” is good, but means nothing. I noticed that they say it very often. This logic is used for product expansion, because you don't want to stop there for a second. Are you afraid of blocks your project.
Here's an example: typical date includes a movie, dinner and a ride home. If the owner of the theater was constantly worried about what will make other businesses would like to gain more, he would put a restaurant in a movie theater and would create a company deliver people home a la taxi. And all three of these services would be disgusting. And then the restaurants started to show films...
But the boss wants it
Yes, quickly make a pie chart. Tons of them.
If the boss is also the product Manager and he has time to make smart holistic decisions, then everything is fine. But if someone tries only to score points in the eyes of others, it will lead to trouble.
But it'll be something that will change our product
Changing product forces you to think about what to do. You can tell everyone about any change and say that it will necessarily change the product, but it is just stories. When you are afraid to make serious decisions, you start to believe that “that's just it, the most”. You're finished with a set of ideas and a repository implementations, but not with the finished product.
Why "no" is so important?
The fact that no one plans to fail. Identifying and clipping the add is quite simple. But the decisions taken while working on a major product is not so simple. They make you read the full description, features and its implementation and say, “This is a really good idea, I understand why it will appeal to our customers. Great job. But we will not add it to the product... That's what we'll do instead.”
From the translator: the article gives a number of reasons why you need to be able to say "no", with illustrative examples and expose fakapov. In fact — how to avoid the provocations from one side or another. At the same time, the author said the main thing — it allows us to say the coveted "Yes". Two things: first, I recommend to read this article; secondly, my position is that we need to be able to correlate the proposed feature with the strategy of the product in General. If a feature does not help in achieving the strategic goal of the frost. Otherwise this is pure "feceris". We don't know who our users are and what they need, so we in any case will make all — the versatile harvester for all occasions. It's a dead end road. I hope that in the near future will find time to summarize my experience a product Manager of Yandex and to write a detailed article on this topic.
The translation is done in the framework of the summer school start-UPS Tolstoy Summer Camp and MetaBeta.
