Enough with Product frameworks and tools, let’s get back to principles.
The attraction towards frameworks and tools in the Product world has distracted many Product People from the Principles that lie behind those frameworks. They have become an end while they should always remain a means.
Principles, once shared and agreed within the whole company (or team) favor convergence contrary to tactics which favor conflicts since they heavily depend on each stakeholder’s own vision of the world.
There are no absolute Principles, everyone can have their own ones, you just have to make them clear and agree on them within your Company. In this article, I share my own list of Principles to give an example. Principles might then be used to build your Product PlayBook or feed your Product Pyramid (see this article).
Never forget that Product Management is simple, even if it is difficult. Principles are the best ways to navigate in this kind of environment.
Here is a list of the principles :
- Ideas (vastly) exceed tech resources ⇒ Focus
- Complexity is always underestimated ⇒ Simplify
- Impact is always overestimated ⇒ Iterate
- Customers lie (unconsciously) ⇒ Observe (behaviors)
- Users don’t (really) care about you ⇒ Be empathic
- Stakeholder management is a waste of time ⇒ Collaborate
- Data tells you what, not why ⇒ Leave your desk
Principle 1 : Ideas (vastly) exceed tech resources ⇒ focus
The rise of software has come with the illusion that everything was now feasible, especially for non tech people. Every problem on Earth could be solved, as long as you have ideas. But everyone has ideas, and problems are infinite. At the same time, tech resources are strongly limited.
Defining Product Management as “solving problems”, which remains a popular definition, is the best way to turn your company into a product factory. You will end up with several features, all average or useless, instead of one or two outstanding ones. Don’t confuse ambition (creating an amazing product) with the number of features (vanity).
How to deal with this Principle ? Focus.
You need to focus. You can’t do it all. Two tactics might help you focus. First, thinking in terms of obstacles rather than problems might help you to focus on the right need. Good news is that there are less needs than problems and of course than solutions (more information about this in the Product pyramid; some might say this pyramid is just another framework: it is, but see it as a means to apply this first principle).
Second, you should sequentialize and focus on one key development instead of parallelizing several ones. This dramatically increases the chance you succeed in building one outstanding feature (but it still remains hard). This implies making hard choices : get rid of some projects to enable a better focus on other projects. You can use the KUB tool (called USP chart in this article, at the end) to ask yourself the right questions.
Principle 2 : Complexity is always underestimated ⇒ Simplify
Complexity is widely underestimated for two main reasons : functional and technical. Functionally, this amazing idea you had walking to the office might impact several existing functions on your app through side effects you did not even have in mind. Not talking about your product marketing. Technically, integrating a new feature always implies some code updates (or to create a huge debt that you will need to pay at some point, double the cost). More about this in the “Revisiting the build trap” article. Pricing model change is probably one of the best examples, impacting deeply both functional and technical dimensions.
How to deal with this principle? Simplify.
Always try to find ways to simplify. PMs usually complain they lack tech resources. I think it is the opposite. They have too much. It’s too “easy” for them to ask for new features, or improvements. What if you had only one developer ? Or no resources at all ? What if you had only one tenth of the time you have ? What would you do ? I know it always seems easier to conduct quick testing for other products than your own: “mine is more technical, more complex, I need A and B fully developed to assess the impact”… Most of the time, it is just that you are the nose in the grindstone…If your product is already live and massive, try to kill unused features that create functional and technical debt… Again, what would you do differently if you had 5 times less resources ?
Principle 3 : Impact is always overestimated ⇒ Iterate
Shipping a feature is like giving birth to it. It’s the beginning of its life, absolutely not the end. Yet, too many people just send a release email to the company after shipping the feature before moving to the next one. Be aware it’s almost impossible to reach the full potential of a feature at first try. Even if it seems right functionally, you need to “educate” it, make it grow, by testing it and getting feedback on the field. You might convince yourself your feature is “ok”, meaning 70% of its full potential. But most of the time, it will never reach 20% of its full potential… The worst thing you could do is move to the next feature. It is the beginning of a vicious circle leading to, again, the build trap.
How to deal with this principle? Iterate.
Force you to iterate at least three times to see how far you can improve your product. When the improvements become marginally better, it’s time to move to the next topic.
Principle 4 : Customers lie (unconsciously) ⇒ Observe (behaviors)
It requires a big deal of self-awareness to be able to deeply understand one’s needs or the reasons that moved one into doing something. Most of the time, one doesn’t have this self-awareness, because one has already too much on one’s head to make the effort. How many times did one ask oneself if one closes one’s door? Which is something quite important! And you expect your users to be helpful when talking to you about their needs and the way they use your product? Come on… Most of them will just lie, even if unconsciously. If you want to give them a chance to become fully aware, you need to listen to them actively (more information about this in this article: What if we stopped asking questions and just started listening?). It might not be enough… You might still be the victim of your own biases, the biggest one being confirmation bias.
How to deal with this principle? Observe behaviors.
Contrary to opinions that customers might tell you, behaviors that you will observe don’t lie. We know it is not always possible to be on the field, but even so it remains possible to observe user’s behaviors (screen sharing works well to see how a user interacts with your app, even if you lose some context). Let me give you a quick example. I remember people saying they hated lining in restaurants when I started my first company. But if you observed them lining up in a restaurant, they were all laughing or chatting. Isolated persons were reading the news, taking a break in an often packed daily schedule… People who were really in a hurry just got their food delivered, that was the truth.
Principle 5 : Users don’t (really) care about you ⇒ Be empathic
We are obsessed with our product. We live for our products. And we think it’s the same for our customers… We set metrics like time spent on our app and we try to grow this metric. But you know what? Customers don’t (really) care about your product. Their life is already packed with dozens of products. Why is it dangerous ? We tend to focus only on our own product journey, forgetting it’s part of a much bigger journey full of enhancement opportunities for our product.
How to deal with this principle? Be empathic.
Try to put yourself in your customer’s shoes. Remember the last time someone asked you to use a new product. How did you react? “Yet another product, user account, new way of doing…” It’s the same for your product. Some users have no choice but to use your product. Do you think they want to spend the maximum of their time on it? Probably not… For the others, what were the substitutes they considered? What will they do once they use your product ? What did they do before ? Asking yourself these questions will give you a much broader view and will help you find new solutions more pertaining for your users…
Principle 6 : Stakeholder management is a waste of time ⇒ Collaborate
So many times product people talk about “managing stakeholders”. I used to say it as well. It now hurts me. “Stakeholders” are part of the team. There are no reasons to manage them, this term conveys the idea of some hidden agenda on both sides. Think about another distortion that appeared recently, this tendency to add “product” in front of every job: Product Marketing, Product Ops… Once again, product people might be too self-centered, trying to solve problems on their own instead of relying on their (seasoned) counterparts in the company.
How to deal with this principle? Collaborate.
Why not simply collaborate? It would imply to consider all stakeholders being part of a Product team before being part of any Business Unit (Product, Tech, Marketing, Sales, Operations…). Remember that an A team is 1000x more efficient than a B team (more about this in “How to do twice the work in half the time, by Jeff Sutherland). But to truly collaborate, one needs the right tools. Why not have a look at the Liberating Structures for instance?
Principle 7 : Data tells you what, not why ⇒ Leave your desk
Data-driven is a quality you will see on almost every product job description. It relies on the belief that the most successful companies in Silicon Valley made their success on data. It is partly true, but remember that for those which did, it is mainly because their business relies on selling data. Simply analyzing data did not help them to find their market fit, data is not a crystal ball. Data tells you what happens, not why it happens. Finding the right metrics is incredibly hard and often requires on-the-field observation to understand what “good” means. More about this topic in this article : “Is being too data-driven dangerous ?”
How to deal with this principle ? Leave your desk.
Your product analytics tool won’t tell you what the solution is. You need to pull up your sleeves, leave your desk, and go onto the field. It might hurt (feedback from customers, behaviors you will observe), it might take time, but you have to do it. It is your job. We are not saying not resorting to data anymore. But start with a qualitative approach to find out the result you expect. Then measure it to know if you are going into the right direction.
If you enjoyed reading this article, feel free to subscribe to my Newsletter (every quarter). It talks about Product, Business, HR, Management… (mix of French and English articles). If you want to have a look at the kind of articles I write, feel free !
If you want to learn more about Discovery, I created a 5 sessions training that keeps improving after every session’s feedback. The average mark is 9,5 out of 10, dozens of respondents coming from top French scale ups.
