Your 4-step guide to building a tech product
As a product manager, you should be familiar with navigating unknown waters. Whether the situation is one where you are building a new product for an unfamiliar audience or adding a new feature to an existing product, all eyes would be on you to build a disruptive product.
Even when surrounded with robust support systems and a talented team of researchers, designers, and engineers, product managers can often feel alone. Why? Because at the end of the day, the success or failure of anything shipped is traced back to this one person who is expected to own everything that goes into building a product. Thus, even for experienced product managers, shipping something new can be a daunting experience, where they have to make sure they leave no room for ambiguity.
Such a thorough approach is overwhelming and sometimes seems impossible to execute flawlessly. The list seems never-ending, and the product manager, constantly under pressure to ‘ship fast, learn fast, and iterate fast,’ can make impulsive decisions.
However, it doesn’t have to be this way, as pointed out by Marty Cagan in his incredible book ‘INSPIRED.’ Referred to as the bible of product management, INSPIRED has helped me in many aspects of my work. Still, most importantly, it has given me a robust framework to ensure what I’m building is valuable, usable, technically feasible, and financially viable.
The framework is simple and involves exploring the answers to 4 questions when building a product:
Is there value in the product?
Answering this question is mainly about gauging two things:
- What are my users’ most crucial pain points?
- Is my product resolving any of those pain points in the best possible way?
Making products that provide a solution to a users’ pain point in the best possible way is where you, as a product manager, can bring value to your users’ lives. That’s when you’ve truly created a valuable product.
On the face of it, the above question regarding the value of a product seems simple to answer. However, it is far from that. Answering this question requires some rigorous user research to understand the personas of your users (who are my users?), what problems they are facing (what are my users’ pain points), how are users currently solving those pain points (who are my competitors and what are their offerings?), and how can my product be positioned so that users switch to it (what is the gap between users’ needs and the solution proposed by competitors?).
The process can sometimes seem redundant, especially when you already have past research on your users that provides some validity to what you are building. However, the world, powered by technology, is continuously changing, and people’s needs are becoming increasingly dynamic. What stands true today may not stand true tomorrow. Hence, running these product discovery activities in a loop is pertinent to keeping your product valuable to the users.
Is this product usable?
You have made a product that solves your users’ pain points in the best possible way? Kudos to you…but that’s not where your job ends (in fact, it’s still far from the endpoint). Often, product managers and designers fall in love with the solution they have built and have this urge to push it to development. But don’t fall for that trap! Yes, the prototypes may seem beautiful and intuitive to you, but you are not the user.
Once the prototypes have been built, whether high or low fidelity, you need to go out to your users and conduct what we call ‘usability testing.’ As part of this testing approach, you and your team observe the user as she navigates through the product to achieve the desired outcome. Be careful, though. Your job is only to watch the user, not lead her to behave in a desired manner.
Note down your learnings from usability testing, go back, and iterate on the designs if needed. Only when your usability testing gives you enough proof that what you have built is usable should you push the prototypes to development.
Is it feasible to build this?
By the nature of her job, a product manager should always understand the constraints within which different teams operate. Even if the product is valuable and usable, the product manager must loop in the engineering teams early in the product discovery process to ensure that what they are planning to build is technically feasible.
I am a strong advocate for involving engineers in the early phases of the product development process. However, in many product teams, I have observed this rarely happens. Product and design work together to build high-fidelity prototypes of a product or feature, looping in engineers only when ‘it is time to code.’
This often results in 3 things:
- Low morale in engineers as they are not able to understand ‘why’ they are building what they are building.
- Hours are spent on handing over the work from designers to engineers, which often results in some aspects of the product being left unexplained.
- Realizing during this stage that what you ideated and designed cannot be built given the technical/architectural constraints.
So, save yourself all this trouble and loop in the engineers when you find a problem to solve. It will not only make your life easy by pumping the morale in engineers and providing them the necessary context but also ensure your team’s efforts are building a feasible product.
Is this product viable for the business?
So, the product you have built is usable, valuable, and feasible? Pat yourself on the back…. while making your way toward the business team leaders and evaluating the viability of what you are building with them.
This involves answering some financial questions: will you be able to break even and eventually monetize from this product? Is it going to drive up your profitability? Is it going to enforce sustainable business growth? These are mandatory concerns you must address before planning your product’s launch.
If you have read the above, I hope you noticed one highlight of a product manager’s life: the multitude of stakeholders we need to have a good relationship with and loop in at various points in decision making. And for me, that is what makes my job so exciting. I work with a diverse set of talented teams to build tech products that empower communities by disrupting the status quo!
