Your Product is not Bulletproof — Drops from my experience as a PM
Through the course of many Product Lifecycles, you eventually come to terms with the unquestionable truth: Your Product can’t handle everything and there’s no silver bullet to achieve that.
That’s right, your Product isn’t perfect, it will never be and that’s fine. Thanks to our fast paced technological evolution, there are plenty of opportunities to address, rendering current solutions a little bit more obsolete day by day. Data mining and behavioral engineering have changed the paradigm of Product Management and development once and for all, this helped shape several analytics tools which support not only technical but most importantly business decisions.
Currently, solutions tend to evolve based on two general concepts:
- Functional Requirements: This category gathers all aspects tangible to customer’s perception of the value your Product represents. This is what we usually call a feature.
- Non-functional Requirements: The elements which compose this category don’t add value to the Product directly, customers don’t notice them until they start experiencing issues with the application. This is where technical debts and infrastructural aspects lie.
In order to keep your Product within high standards’ range, you need to evaluate the aforementioned concepts in detail, thus requiring the usage of meaningful metrics, that depend on which requirements you want to address.
When evaluating functional requirements, you should definitely establish a Product Discovery culture, given it’s a never ending process of self-healing and improvement. It first starts with the question “What’s the value proposition of my application?” then followed by “Is the value proposition aligned with overall Market’s needs?”.
Those questions are the starting point to help you focus on what really matters, if you’re not used to run Discoveries, more often than not, you’ll find yourself in a situation where you have a Backlog filled with things you don’t quite understand the impact they’re going to make and why they are there on the first place. Therefore, when asking yourself those questions, it becomes natural to gather data and implement metrics that help understand what and why is something valuable to the product.
Let’s take B2B organizations for instance, it’s definitely helpful understanding metrics such as CAC (customer acquistion cost), NPS (net promoter score), LTV (lifetime value) and churn rate for example. Those quantitative indicators analyzed together with qualitative indicators, which are usually extracted from surveys, competition and market analysis, are a powerful “compass” to help you identifying what the next steps should look like.
When we discuss about non-functional requirements, those are more easily identified, given they’re associated to how the application is architectured. For example, when changing customers from On-Premise model to SaaS, at the end of the day, the user exeperience should at least be the same, if not better than what it used to be. Besides, when you have a legacy solution and need to refactor it due to component’s deprecation, this is also something required to keep your operation running, however it’s transparent to the client base.
In short, there will always be either something the market will require your solution to have, or a technical debt you need to get rid of in order to keep the application efficient and responsive. The beauty of Product Management is mixing both of these, focusing at the end of the rainbow. You won’t reach the golden pot, however the closer you are to it, the brighter you see its glow.
