Make Products Great Again
In my previous article I shared a set of questions to help you boost the quality of your user stories and roadmaps. I used the 3 Forces of Product (Right Thing, Thing Right, Build it Fast) as a framework to classify the questions. Now let’s focus on how different stakeholders exercise their influence, often unconsciously, to push towards one force or the other, and how can you leverage that when needed.
All Product Managers have been in this situation: a ‘Head of x’ wants to have a deadline for a product or feature, the designer is not happy with the looks of it and engineers are stuck waiting for some dependency to be handled.
At the same time, your feature is blocking the roadmap of another team.
What about the customer? That one is long forgotten. When you realize it you are not building the product for the customer anymore, but to keep your stakeholders happy and your team busy.
All eyes are on you, your inbox is growing exponentially and all you want is to hide in a remote corner of the office to get some work done.
How did you get to this situation? Probably by not following this set of questions.
Let’s take a deep breath, put those product skills at work and do what you know the best: break down the problem into small steps.
1) Focus on the Right Thing. The order of the factors DOES alter the product
First things first, let’s make the customer happy again. Velocity or quality won’t solve a problem by themselves.
In order to narrow down the topic of this article, let’s assume that you already have a product to work on, for which certain customer jobs-to-be-done have been identified. You can use the questions from the first part of this article to find out whether the problem you are trying to solve is really worth solving.
Focus on the problem, not the solution, and commit to outcomes, not features. This is so important that I’m going to shout it for you:
PROBLEMS, NOT SOLUTIONS
OUTCOMES, NOT FEATURES
And just in case it’s not clear yet, here goes a graphic description of what will happen if you don’t focus on the right thing:
The solution bias
Focusing on solutions is the easy thing to do. We all think of solutions, because we see them everywhere. When you look at a competitor’s website, when you are using a certain product, you are interacting with solutions that have been created to solve problems. And unless we deal with a totally new and unexpected problem, we tend to set ourselves on automatic mode, trigger those previous experiences in our mind and look for known solutions. Familiarity makes us lean towards solution bias.
“Jumping to conclusions is a safer sport in the world of our imagination than it is in reality.”
― Daniel Kahneman, Thinking, Fast and Slow
Familiarity is not always a bad thing, and often we want to have our customers on automatic mode, we don’t want them to think. However that’s part of the solution, the Thing Right, not the Right Thing. We will get there.
It is only by focusing on the problem that we can begin to think outside the box and consider a wide range of options, both tried before and new. Without getting out of the topic of this article, there are plenty of ideation technique resources and such a wide and important topic requires separate commentary.
2) Find out who wants what and why
The Right Thing:
- Customer: Here is where everything should begin. The customer has a pain that we want to solve. That should always be the core of whatever we do with our product. Customers don’t need to care about how we do it, and perhaps not even about what we do. As long as we find the why, the source of a problem, and our product answers it, that’s all the customer will care about.
- Product Manager: Their main job is to cure customer pains, facilitate jobs-to-be-done, answer needs, known or unknown, by means of their products. The challenge often is ensuring we are working on the right ones.
- UX designer: Together with PMs, UX designers tend to focus both on discovery and delivery. In cases when the company has dedicated research resources, discovery could get a bit detached from designers. It is important to keep the involvement in discovery, as it will help create awareness and ownership of the customer challenges. By means of different techniques, UX should enable the Product team discovering what is that right thing.
- BI / Analytics: Generally supporting Product teams from a data analysis perspective. Their input could be crucial to, first of all, understand what’s the right thing to work on, and second, to understand what’s the impact of our actions.
The Thing Right:
- Back end engineer: They are accountable for the architecture, thus for the stability, reliability and technical performance of your Product. It is only logical that they want to make it happen right.
- UX Designer: They are accountable for how your product looks and feels to the customer. They also want to ensure that customers get answers to their needs in a smooth and frictionless way.
- Front end engineer: Pretty much between the two above, they are the ones who “make it happen”, they make products tangible. Front enders want to ensure that the customer does what it has to do, and that customer-product interaction runs as smooth as possible.
Build it Fast:
- Product Manager: Often under pressure from Senior Managers, Leaders or ‘Heads of..’. As main point of contact with stakeholders outside of the team, they will generally be accountable for delivering the product on time.
- ‘Head of..’: Also under pressure, in this case by upper management layers, investors and business performance metrics in general. The luxury of time is very scarce at this level.
- Customer: If you have a pain you want to cure it asap. No need to elaborate or illustrate it further, as day-to-day we are all customers of a myriad of products.
3) Find the balance
Note: As much as I try to please the analytical mini-me screaming in my head right now, this model is extremely subjective, as it not only depends on the kind and amount of stakeholders around your product, but on the power and influence you and each of them can exercise on product decisions.
These are the variables we need to consider in order to visualize the product positioning on the diagrams displayed below:
- Stakeholders (both internal and external) with influence on your products.
- Interests of your stakeholders. Described in the previous section. Defines the position of the stakeholder on the diagram.
- Decision power of your stakeholders. Subjective and hard to quantify, usually (and unfortunately) guided by corporate rank or status, but also often (fortunately) guided by expertise and experience. Defines the size of the stakeholder on the diagram.
- Influential power of your stakeholders. Combination of social skills, communication skills, character traits, attitudes and emotional intelligence amongst others. Also subjective, but more important than Decision power, as with it you can indirectly but effectively participate in decisions despite not being the decision maker. Defines the length of the stakeholder arrow in the diagram.
- Hard constraints. How much room and flexibility you have to move within the three forces. We can think of it in extremes as in: it absolutely needs to do x, look like y or be ready for z, otherwise the product will be completely useless (e.g. we can’t fuel a plane with lemonade when it has already taken off). Defines the size of the diagram areas.
- The Product or Products that your teams are responsible for.
You should always try to keep your Product, not you, at the center of the diagram. Setting yourself at the center without considering where all other stakeholders exercise their influence, would automatically outbalance the equilibrium.
Now let’s see how Product Managers can play out in different scenarios. The images on the left provide a scenario, the images on the right show in which direction the PM should pull to get the Product (represented by a rocket) in the sweet spot. You can think of it as a “tug of war” game, the arrows being sides of the rope where every stakeholder exercises his/her influence.
A) Engineers with high influential and high decision power. UX with small influential and small decision power:
This is a frequent scenario in products with complex architectures and standard or familiar interfaces (e.g. messaging platforms). These kind of products can become monsters if not properly broken down into small but meaningful chunks with clear boundaries. If we fail to do so, we can let them grow in complexity, distancing ourselves from the initial purpose. Product Managers can help ensuring that focus stays clear. Setting milestones or defining deliverables can help maintaining optimal velocity.
B) ‘Heads of..’ with high influential and high decision power. Engineers with small influential and small decision power:
HIPPO-driven decisions tend to lead to these kind of scenarios. A culture that takes all Senior Managers’ opinions as mandates and that doesn’t challenge them is a very dangerous place to be. The typical outcome of this will be an overcomplicated feature that doesn’t solve any problem. A good way for Product Managers to handle this situation is by playing the UX card. In case of strong top-down companies, a good approach could be finding the simplest way to validate the Senior’s assumptions. If possible, this could be done by means of wireframing or rapid prototyping, decoupling this piece of research from the actual development.
C) Analysts and researchers with high influential and decision power. Engineers with small influential and decision power. Time constraints:
This can happen in cases of high uncertainty, for example, when launching products in unexplored areas that are not linked to the main business activity. It is only logical that we put some extra effort on research when we want to build something from the ground up. Although we probably don’t want to spend too much time / resources in an area that we don’t know will bring anything back to the business. On one hand we want to ensure we keep the focus narrow (don’t try to discover / validate too many things at once), on the other hand we can afford a bit of rawness (do not optimize something you don’t know yet its value). Having time constraints could be actually useful ensuring that we do not over-explore too early.
D) ‘Heads of..’ with high influential power. All other stakeholders with small influential and small decision power:
Similar to B, however wasting even more resources. This can be the case of leadership pet-projects. It can also happen with personal initiatives that succeeded at a previous venture of the executive in question. Probably the most difficult ones to handle. If the UX card doesn’t work, sometimes the best approach is to embrace failure and learn the lesson.
Summing up, Product Managers can wear multiple hats. It is only by deeply understanding the problems we are trying to solve and how each stakeholder plays their part, that PMs can effectively exercise their influence and decision power in order to find the sweet spot for their Products.
This is far from an exact science and it’s not a static canvas. As a process consisting of human interactions it will keep evolving throughout the product lifecycle. Certain stakeholders will appear in scene early, others will do so later, thus it is important to keep a fresh picture of the situation. For example, as deadlines approach a sense of urgency may arise, constraining the Velocity area and moving stakeholders towards it. It is important that Product Managers are aware of these kind of scenarios in order to rebalance the situation and help maintaining focus on Quality and Value.
Thanks for your time, and as always, feel free to share thoughts, ideas or suggestions if you have encountered any similar situations. Found this post useful? Kindly tap ❤ below :)
Resources and further reading on this topic:
An Introduction to Product Discovery - Product Talk
I continue to be surprised by how many product managers aren't familiar with dual-track development. I don't care if…
A product discovery framework for those that want to Innovate
In October 2014, I coached a (very) cross functional team at Spotify, tasked with discovering what the ideal running…
Discovery : UX Apprentice
Dig deep into the process and logic of user experience during discovery. Solve the big problems, one sketch at a time.…
Agile Product Ownership in a Nutshell
This is basically a 1 day product ownership course compressed into a 15 minute animated presentation. Some call it …