In my recent articles, I’ve been discussing why “business demands => technology implements” doesn’t work, why business people hate discovery and I’ve introduced the concept of MVD (Minimum Viable Discovery).
Today I’ll talk about every Product Manager’s #1 priority which, I believe, will be a good addition to the 3 articles cited above.
Quiz
To start this article, I want to propose a quiz. Based on your experience, what is every Product Manager’s #1 priority?
Let’s analyze each of the answers above to find the correct answer and better understand why this is the correct answer:
I’ve already mentioned in the past that creating the vision is critical for every product leader and every product manager to do their job. Without:
It is very difficult to do anything with your product. How do you prioritize without knowing where you should lead your product? How to say no to the constant requests from your product’s stakeholders (company employees, customers, partners)? From this vision, a Product Manager can create a clear strategy on how to execute this vision. However, this is not the Product Manager’s #1 priority. It is a means to get this #1 priority.
This is what I’ve been discussing in my latest articles and this is very important to get to the Product Manager’s #1 priority. We must never jump directly to implementing solutions, not when asked by business people to implement their demand and not when knowing about a problem and start implementing the first solution that comes to mind. We know that as we learn something about a problem, we should also map solution hypotheses, and test these solutions as fast as possible so we can deliver the best solution as fast as possible. However, as the first answer, this is not the #1 priority. Again, it’s a means to an end.
This answer is a variation of the above question just making explicit a good tool to iterate from problem to solution, the Opportunity Tree. I mentioned this tool in my article about the two sides of product discovery. It helps a product team better understand the expected outcome, map the opportunities that can generate the outcome, generate possible solutions for the opportunities and build experiments to test the solutions. However, this answer is a little worse than the previous answer because it talks about creating a complete opportunity tree. We should use the opportunity tree to have a good enough understanding of the problem to scope out possible solutions and get to the expected result (outcome) as fast as possible. And again, this is a means to an end. It’s not the Product Manager’s #1 priority.
So let’s put it all together and make it the Product Manager’s #1 priority, right? No! As explained above, these are all tools that a Product Manager can use to get to her #1 priority. Besides that, I believe it’s quite easy to understand why this one is not the correct answer. We are asking what’s every Product Manager’s #1 priority, so this priority cannot be 3 things. It must be only one thing! This is a common mistake some Product Managers incur, having more than one priority. When a product manager is asked what are her priorities, she cites a list of things, which is somewhat ok if, and only if, she knows and constantly works on her #1 priority, which we will know what it is pretty soon! (=
I guess that after reading the explanation of why the previous 4 answers are incorrect, you probably know that “none of the above” is the correct answer. However, despite the fact that this is the correct answer, it’s still unclear what’s the Product Manager’s #1 priority. Even though I gave some hints above, let me now make it explicit.
Let me repeat this one more time: every Product Manager’s #1 priority is to generate results as fast as possible.
As I mentioned in the comments about each of the answers above, answers 1., 2. and 3. are all means to an end, and this end is to generate results as fast as possible. Generate results for the company that owns the product and invests in building the product, and results for the customer, i.e., solve her problems and address her needs. It needs to be as fast as possible because generating results costs money and the more time we spent on generating results, the more money we will spend.
Above I cited some good tools to get results, but we should not forget that these are tools to help us generate results as fast as possible. OKR, roadmap, proof of concept, MVP, MVD, discovery, usability test, prototype, no-code/low-code, site, app, feature, bot, algorithm, opportunity tree, power x interest mapping, RASCI, BCG matrix, technology adoption curve, team structure, Tuckman’s model, Conway’s law, agile, lean, and the list can go on and on, but all of these are tools so we can generate results for the business and for the customer. Even the product, the very thing that goes in the title of the Product Manager’s function, is a tool to generate results.
By the way, generating results as fast as possible is not the Product Manager’s #1 priority only. It is the entire product development team’s #1 priority. Engineers, Product Designers, and Product Managers in product teams as well as in structural teams (data, devops, architecture, etc). The team must have always a common #1 priority to be a team. Otherwise, they will be a group of people working on different priorities that happens to seat together (or have a slack group for remote teams) and happens to have periodic planning and update sessions. And this #1 priority is generating results as fast as possible.
I gave some examples of the focus on results in my previous articles. I want to give another example from Lopes, the biggest real estate company in Brazil, where I lead the digital transformation efforts.
In order to sell properties from a new building, Lopes and the builder company create a partnership relationship where the builder company shares info about pricing, unit availability, and leads, and Lopes works on selling units based on its large experience commercializing new builds. In order to perform its attributions in this partnership, we need to know from the builder the prices of each unit that change frequently depending on the sales evolution, the available units, and we need to receive leads from the builder. This information was sent through files to be imported manually into our system. All manual information input tends to be slow and subject to errors, so it is clear to see that this manual integration was sub-optimal. Lopes integration with the builder companies was no different. Since it was a manual operation it was made once or twice per week, which could potentially generate outdated information about pricing and units available in our systems for brokers to use. Also, the older the lead information gets the colder it becomes, and probably the potential client figures out other ways to receive the information she needs and eventually closes a deal with another seller.
So, here’s how we solved this problem using the opportunity tree, always focused on generating results as fast as possible:
We opted for Solution 3 because it was the one that would bring us results faster. It took us just a few weeks to have the first RPA up and running and bringing results. We are using this solution for more than one year. Still, no APIs were provided by the management system providers, and haven’t had the need to build our own RPAs. The RPA provider works ok with a reasonable cost and we can focus our team to generate results from other opportunities.
I’ve been helping several companies extract more value and results from their digital products. Check here how I can help you and your company.
Do you work with digital products? Do you want to know more about how to manage a digital product to increase its chances of success, solve its user’s problems and achieve the company objectives? Check out my Digital Product Management bundle with my 3 books where I share what I learned during my 30+ years of experience in creating and managing digital products:
You can also acquire the books individually, by clicking on their titles above.