Over the last five years of my product management path, I have come across some interesting product management discussions. The most common questions from these conversations were,
The onus, to address these questions, lies significantly on the product manager. As a product manager, you can never work in a silo. You need to interact with internal stakeholders, engineering teams, and most importantly with the customers. In this article, I document a framework to inspire your product teams to build products.
Before that however, there is an even more important question that needs to be addressed — Why? Whether it is improving the current product line, building a new product, deciding on potential partnerships, understanding customer behaviour or proposing new products for tapping new revenue streams.
The answer to "Why?" is what helps product teams take better decisions and enables them towards success.
Understand the vision of the company. I always recommend that you start by gathering a thorough knowledge of what the company is trying to do, what the company's mission is, and what the founding team's vision is. Interview the founding team to get a high level understanding of their 8-year plan or 5-year plan. If you're part of a younger company, the 5-year or 3-year vision. As a product manager, it's in your hands to bridge the gap between business stakeholders and product strategy. You have to take action and translate a long-term plan into proactive short-team action.
During my time at Devthon, I'd inevitably end up with many partnership proposals. I never wanted to say no. But when I went back to the table to discuss partnerships with my founding team, we would always ask ourselves, "Does this partnership enable our vision?" This is where I learnt to say NO. If you're someone struggling to say no, this exercise will help you take decisions which carry the vision forward. You will find that it becomes easier to say no - now that you also have convincing reason to say no, or yes!
Key Themes. If you have succeeded in understanding the vision of the company, move further to draft the key themes the company is willing to identify itself with. What would it like the customers to associate you and your products with? Trust, Expertise, Usability, Secure, Speed, Happiness? This point might sound insignificant, but you will see how much it matters once it trickles down to roadmap or sprint process. You will start asking yourself more often than ever, "Does this feature help the customer associate us with the key themes?" "Does this blog post reflect any of the key themes?" "Does this action mirror any of the key themes?" And so on.
Areas of Focus. Wait. But, this sounds very similar to Key Themes. Read on, and you will soon realize that this is quite different. Going back to the time I was part of Devthon, we focussed strongly on our innovation process - it was our key to an efficient business model. All our efforts were focussed on driving this innovation process that we designed after two years of experience, building product teams, and leading them towards product development. As the company and product start to grow, it starts to perceive opportunities in other areas. Devthon started with its focus on the education sector. The innovation process spread like wildfire around educational institutions. New ideas have potential revenue streams that surely add value to a company. But when you have defined focus areas, you have a guideline to pause and understand the decision. Focus areas are never fixed. A company is free to amend it every 2 quarters or annually. It helps everyone to stay focussed and accountable.
Metrics. All of the above is left without purpose if success cannot be measured. How can you say that your team or product or company has succeeded? What guides actions and decision? It is a set of quantifiable points that can be measured and achieved. And, data is currently the only way for us to gauge success. It's often easy to get overwhelmed while building a product with feedback from customers, suggestions from investors, or even ideas from the team. It's hard not to lose track. It's even harder not to start measuring wrong data points - And still end up cheering false success. This framework provides a way to structure the madness it is to build products.
It is important to also understand that product teams, especially engineers, love clarity. But instead of telling them what to do, use the framework to your advantage and present them with challenges. You will be surprised at how the team comes together, takes the right decision autonomously, ships solutions that delights customers, and further derives the right metrics to constantly improve products.
Product teams don't need to be told what to build or how to build it - Inspire them by collaboratively identifying unmet needs.
Product managers don't just understand how to set a vision, collect and analyze data, they come with other skills that can only be gathered through experience. For example, if you're a product manager you will know that you can't just base data on a percentage or number it also needs a relative measure to time and more importantly qualitative. Or for that time when you think you moved a metric, but realized it had a domino-effect on another metric.