Product Strategy — are you using techniques and tools properly? (part 2)
Connection
In the first part of this two-part series on Product Strategy, I started with some provocations:
- When we talk about frameworks or work tools, how much do you really question whether this tool will actually be useful for your context?
- Do you just use the X / Y / Z tool or do you test and observe the results, until you find a tool that solves your problem?
- Do you know how to clearly identify your problems?
And before I started to answer how I organize myself with these questions, I realized that I needed to take a step back and explain an extremely complex concept that is also related to this answer: What is a product strategy? If you have read my previous article, you already know some points of Product Strategy. But that’s not what I’m going to talk about here. Let’s go to what matters: if I ask you the following questions, what would your answers be?
- Why do you put your initiatives on a timeline as a “roadmap”?
- Why do you divide your time into periods of two weeks (sprint)? Or even 3 months (quarter)?
- Why do you write tasks in a user story format?
- Why do you create paced meetings to present things to important and interested people (stakeholders)?
- Why do you prioritize developing one feature over another?
- Why do you calculate the amount of tasks that your team finishes in a period of time?
So, among a thousand others that came to me… If you do a critical analysis, do you know how to use the many tools, frameworks, methods? And more than that, can you prioritize which tools you should take and use to solve something?
Organization
To organize myself into a new team or a new challenge, I use to start this organization with the following question:
Is my team an empowered product team and can we think and attack clear goals with autonomy and servant leadership?
If not, which is the vast majority of product teams on the face of the earth, I organize what I need to tackle in order to achieve this goal, based on the 4 pillars of the product strategy I shared earlier:
1- Focus
2- Insight
3- Action
4- Management
To achieve high efficiency in teams of product development, I know that I need to get close to these four points. Or at least know the way there. And for that, I separate every small detail of what I need to do / have and what is my strategy to get there based on my current moment in terms of Team, Product, User / Client, Company, Business and Culture.
That’s where the next topic comes in:
Explanation
Based on these 4 pillars of the strategy according to Marty Cagan, I organize our needs as a team and product. And as in a mind map, I get to the technique that I believe solves my problem.
To explain what this mind map looks like and my logic behind it, I’ll briefly take the example of FOCUS:
“[…] What matters is your ability to focus on really critical problems and not just prioritize a list of bugs or ideas. It means taking a problem and putting things into production until you reach the expected value that indicates that the problem is being solved. Or achieve an important business objective.”
Citation from the previous article.
And for you to be focused, you need to create a shared vision of what you hope to solve for real users / customers that are connected with the business. There must be a symbiosis between your product vision and the company vision.
But…
> To have focus, product vision is needed.
>> To have product vision, a shared vision with your stakeholders needs to be created.
>>> And to have a shared vision, you need to put together your thinking and share it with several people in a safe, efficient, clear and iterative way.
>>>> So, for that, what if you try to create a one-pager product vision (one-page document with the main points of your product)?
1- Ability to focus on one problem;
2- So, you’ll need to create a product vision;
3- For that, create a shared vision will be necessary;
4- Tools: one-pager, roadmap and OKR.
Here is the EUREKA moment! Wait, I already know my expected goal: to communicate clearly, efficiently and, above all, connect interests. And I have a range of tools for that. If I want to go even deeper, within a shared vision, I can first create a map of the stakeholders to understand who I needed to align, communicate or interact with. Then, more efficiently, reach the expected goal.
And before you think that one-pager can be effective or not, that you would make a roadmap in that case, that would share the OKR… Think that
before the tool, there is a need and the scenario you are inserted into. Learn to dance like the music. Do your coworkers use the output roadmap more to communicate and align product vision? You do not agree with the technique, but how can you adapt to having a shared and clear vision of the objectives?
Before quoting, extolling or criticizing a tool or technique, organize the expected outcome. And be clear about the indicators that this technique is solving your problem. And take note of what is not working.
At the end of the day, it doesn’t matter if you use all the techniques perfectly, if you know how to run scrum, kanban and whatever. What really matters is changing the world and moving the needle of the company and your product. It’s basing your decisions on data and clear information for you and for the company, whether they are more empirical or not.
And of course, after you find out that this is the game, play to increase the efficiency of the whole. But never lose your curiosity and your instinct to question the “whys” of life.
