“We’d like to make them mini-CEOs” is often the demand from companies looking to develop their Product team. But what does that mean in practice and where do you start? And is it even the right thing to aim for? In this article we will dive deep into how to make your Product team more ready for what’s ahead, regardless of the market and area where your company does business. However, before we do that, let’s first describe the way we like to think about Product competencies in general.
A lot of companies still start with perceiving Product roles as mostly delivery-related. The reason being that the “real” decisions are usually made at the top and the PM/POs end up being just backlog managers that “make sure stuff gets delivered.”. There are of course many reasons why this setup is so common. One of them being that the Leadership team does not really want to let go of the “control” of the direction of the company or its products because they believe that it’s solely their responsibility. The other most common and tightly connected with the first is lack of trust in the skills and competencies of their Product team. So you end up in a chicken/egg situation. But how to solve this dilemma?
Developing your product team is not just a matter of “adding skills” one by one, there are multiple layers to it and for example to be able to influence company goals and objectives you need to be able to first create and evaluate the right metrics. Otherwise your inputs will lack the needed evidence and product thinking.
So let’s have a look – what are the different layers of Product management skills?
Customer feedback and research
There is a universal agreement that virtually every product role should, to some degree, work with customers and their feedback. However, it’s not as easy as just talking to them or sending out surveys – there are multiple levels to the skill of working with feedback so let’s have a look at what are the crucial parts of it.
i. Knowledge of multiple research techniques
Surveys and interviews are just the top of the iceberg here. Do you remember DropBox? Their whole cloud storage business started with a landing page with which they measured how many people would be interested in what they have to offer. As the saying goes “Software development is the most expensive way to validate an idea.” Every great PM/PO has to have a set of tools up his/her sleeve to not let the wrong ideas get to the Development stage. Whether it’s the landing page, fake door test, A/B testing, semi-structured interviews – you can pick your favorite, just make sure you don’t develop first and ask questions later.
ii. Creating and leading a customer interview, so that it doesn’t skew the results of your research
Leading a customer interview in a non-native language while understanding the nuances of asking the right questions makes a huge difference in the data you get from your customers. Here the key is understanding how biases work and how to avoid them in your questions (e.g. double-barrelled questions) or in interpreting feedback.
iii. Managing feedback
After this, you should have loads of customer feedback in various different forms. Here the question is – how to manage it? Ideally have one tool where you can systematically work with it – whether it’s ProductBoard or Jira Product Discovery, the key is to have it all in one place. Once you have it captured and categorized, also make sure to share it with not only the stakeholders but also the team. Since in most cases they are the experts that can help you in designing the right solution for customers’ problems.
Evaluating success and working with metrics
We have seen this time and time again – many POs (or even their managers) believe that success is measured by a delivered Sprint/Feature but it couldn’t be further from the truth. The days of “just delivering features” are long gone and for the companies to benefit from real product management work the focus needs to be on metrics and measurable outcomes. And for the metrics to work, you need to be able to formulate a hypothesis that does not take more than a couple of months to validate on the market. And achieving or trending towards these goals is what Product teams should be evaluated by.
On the other hand, you also need to factor in the costs of development. And as you can see in Martin’s previous article here, it might not be as complicated as you might think.
Discovering what’s possible (a.k.a. the biggest product buzzword – Product discovery)
Discovery is getting so much traction these days, and to be honest, there is so much misunderstanding surrounding it. Let’s be honest here, not every company is at a stage where it can explore or create new products/services. For many of them it doesn’t even make sense. But that’s the thing with Product discovery – it’s not just about creating something new that has never been done before or exploring a Blue Ocean strategy, although that’s the way it’s presented a lot. The main objective of Product discovery is to
- gain a holistic understanding of what customers need/want
- discover how your team(s) can solve them
- understand how your product delivers value
All of that is encapsulated with a single objective – to maximize the impact of your work.
That, very simply put, is what Product discovery is all about. What you should understand is that there is already so much you can do with your product without organizing a Design Sprint or doing many time-consuming user interviews. If you don’t know where to start, here are a couple of ideas.
- Create a User Journey Map for your product.
- Gather all data, feedback and information about your customers/users into one “Customer knowledge base” (regardless of the tool, this is a must-have for every Product team).
- Visualize all Business priorities and Business risks, because in the end it’s not just about the customer wanting something. It’s also about that “something” fitting into the business strategy for your company.
Selling what you discovered as a potential way forward (a.k.a. Master the skill of Storytelling)
Imagine you have all of the above – now’s the time to put on your sales shoes and start selling. Because even the best idea will not get executed if you are not able to sell it to the Board, top management or your team when it comes to delivery. Storytelling is so underrated as a Product skill but without mastering it, someone else’s ideas usually win. If you want to start with some self-study, Talk Like TED is a great book to read. Here also the feedback loop of your peers, superiors and your team are critical. Make sure you ask regularly and ask specifically what can be improved before you deliver any presentation or a “sales pitch”. And as with every “soft” skill, practice makes perfect so just make sure you consciously and continuously improve.
You’ve sold it – can you deliver?
So you have the “real basics” covered – now let’s turn our attention to your team and its delivery. How can you help them best from your Product role? Here is where storytelling comes into play again, as whatever is in the end decided as the way to go, you have to be able to sell to the team. And by selling, we mean together with the full context, variants and risks considered etc. so that the team knows, there is a rationale behind everything we decide to do.
Once you start designing details of a feature/solution (or shaping if you use Shape Up), your focus should be to help with identifying potential for scope cutting, edge cases, etc. Because you know that at some point the team will say “It’s impossible to cut it into smaller pieces.” However your job is also to guide the team in not cutting scope too much, and staying true to the principles of building actual user value incrementally.
And lastly, whenever a big change comes, whether it’s a market thing, an incident, a delivery delay or a strategic top down priority – how you react matters a lot and sets the tone in how the team is going to react. First of all, transparently communicating what happened and why and of course updating the timelines and managing expectations is the key here. What you want to avoid is the feeling that you make a promise e.g. at the beginning of a quarter and due to unforeseen circumstances, the situation and priorities change and you are dealing with a disappointment that could have been avoided with early communication. Whenever a delay/change of priorities happens – update all the expectations and promises to make sure everyone knows the impact. Remember, the goal is not to deliver 100% of the quarterly roadmap or even a Sprint, the goal is to deliver stuff that has the biggest business impact.
Done with all of the above? Now you can start looking ahead.
We’ve mentioned roadmaps, but how are they created is the question right? We have a saying that whenever you don’t have a plan, someone else will create it for you – and that’s what you want to avoid. If you have all of the above covered, you should feel confident enough to build a plan for your team(s) for the upcoming couple of months and present it to your stakeholders (practicing the storytelling in the process 🙂). And if someone challenges the plan, it’s perfectly fine, but you have to start with something that you as the Product expert believe is valuable to the company based on the data, business knowledge and customer insights that you already have. For start, feel free to use this Now-Next-Later roadmap. As you see, this also helps in the paradigm shift from delivering features to measuring actual business value.
Wait…you did not mention strategy at all?
As we’ve mentioned in the beginning of the article, there are multiple layers to the Product skills. And to gain the trust of your leadership team to influence company strategy, you need to first excel at all of the above. How to utilize that in Product strategy, is a topic for one of our future articles so stay tuned 🔜.
Authors: Pavol Sojčík and Martin Michalik
