Tracking and Measuring Product Lifecycle

Kamal Srinivasan
4 min readApr 24, 2020

--

Tracking and measuring a product lifecycle to understand the truth for all stakeholders is an ongoing challenge and countless meetings across organizations. As I was writing this article, I got a request from an ex-colleague requesting a recommendation for a tool that helps maintain the source of truth where different departments can track from ideation to product launch. As we all are turning to the reality of remote work, the ability to create visibility across a product lifecycle is more important now than ever.

Developers have a gamut of tools that helps them get organized, measure productivity, and understand the impact. It is rightly so, given there are anywhere near10:1 of Engineers to Product Managers. Program Managers also have a growing number of tools like Confluence, Asana, Trello, etc., over the last few years to improve productivity. There is some overlap in Program Management tools being useful for the Product roadmap. Specifically, when the customer problem is scoped and product management is about feature development. But, tracking the product lifecycle in most organizations involves a cluster of tools from Word, Powerpoint, Excel, Smartsheet, Wiki, and Jira. The more complex a program, the more tools, and repositories come into play. The harder it gets in managing the program across the product lifecycle.

Somewhere in these documents, we have the truth!

The nature of agile product development implies we can go fast, but some stakeholders do feel left out of the process. I have seen organizations spending about 5 hrs/week and close to a sprint worth of time/quarter tracking, evaluating, and measuring product lifecycle.

Some of these problems manifested are:

  • Communicating Vision — Drafting and communicating vision within the organization is important to rally the team towards a common goal. This vision gets translated into product strategy. In this translation, top-down vision gets drafted, and it floats in a Word document. How do you tie this to the measurable OKRs in a product? There are some tools like ally.io to track OKRs, but then again it becomes yet another Word document replacement not a single place of truth.
  • Voice of the customer — Customer work backward strategy can be done through PR/FAQ, but what about the customer meetings and copious amounts of data from a customer. How to capture and bring the voice of the customer into product development? There are periodic customer conversations that help clarify fine-grained requirements, but capturing this is always a scattered set of places like Jira, BRD, Confluence.
  • Product Development — Bringing visibility into product progress across the organization. Cross-functional teams like sales, support, ops, and marketing that would like to understand product progress. Keeping them updated is essential for product launch and customer adoption to be successful.
  • Customer Beta program — The beta program is an effective way to measure and calibrate customer feedback against product expectations. Some of the best products in the market have had early and iterative customer feedback cycles to make them an effective product-customer fit. But, intent to run a Beta program does not equate to effective feedback. Since most organizations lack the infrastructure and tools to run and measure Beta programs effectively.
  • Product Launch — Tracking Go-to-market alignment along with product development is integral to the successful adoption of a product by customers and internal stakeholders. Tools that provide product launch tracking like go-to-market are typically outside of product development. Going to a fail-fast world, product development and product launch need to be aligned.
  • Knowledge transfer — I might be dating myself by talking about KT. When you are trying to get customer feedback early and often, having customer success teams, and support teams integral to product development is key to success. But, there is no easy way to do enablement without the traditional heavy lifting. How do you keep support teams learning and testing the product as features come online with sprint cycles and not when everything is polished? For them to test on the heels of product development support teams need an easy way to track where to consume and what to consume and test.
  • Metrics and KPIs — Most product organizations have key product metrics they track, but don’t have the best way to communicate these across stakeholders. It shows up in Powerpoint or a Tableau dashboard, but lacks a single place of truth from vision to these metrics.
  • Weekly Business Reviews — Conducting reviews where progress can be monitored across the Product Development and Product Launch activities in a unified way. I can’t tell you the number of times we have regurgitated better ways to communicate product dashboards in weekly reviews and still fell short of meeting the needs of all stakeholders. We need both a top-down and bottoms-up way to monitor progress.

For products with little cross-functional dependency, it is easy to track and measure success across the organization. It gets harder to manage the product lifecycle as the complexity of the product spans multiple teams. These problems manifest in various scales across organizations of all sizes.

A unified repository to follow the product lifecycle from Vision -> Product Strategy -> PRFAQ -> Initiatives -> PRD -> Product Launch -> Customer feedback -> Product enhancements will bring visibility, improve KPIs, track dependencies better, measure success, and align the organization around common goals.

In the next part, I’ll discuss solutions that have worked (or somewhat worked). Will also discuss the effectiveness of tools like “Aha!”. Share your feedback in comments and if you have had more effective ways to track/measure product lifecycle.

--

--