Purpose Driven Product Development

Product development can be described as an elastic relationship that impacts many disciplines and stakeholders. For example, Business demands predictability and Product Development Teams seek autonomy to drive execution and further grow identity.

Whenever I have to understand the state of Product development, often I am referred to a Product Backlog and/or a Product Roadmap.

In general, Product Backlogs consist of a single column with many line items – user stories, epics, features and bugs. Creating and managing the long list of items is many times a full time job.

Product Roadmaps typically are represented by a Gantt chart. Time runs along the horizontal axis, and stacks of horizontal rectangles with varying widths represent features or epics. It is never clear upfront if there is room to test & learn within the allotted time.

Aside from Product Backlogs and Product Roadmaps, the state of Product development can be impacted by these common scenarios:

• Business wants to stop product development because market is underperforming
• Business wants to understand why date was missed and wants a new forecast
• Development team needs more headcount
• Some team members are moved to another Development team unexpectedly

It is fair to claim that all of the above scenarios do not result in increased happiness despite having a Product Backlog and/or Product Roadmap. But why?

I believe that before we create a Product Backlog and/or a Product Roadmap, we need to define a purpose driven decision making framework. The motivation is to minimize disruption to the organization.

What elements do we want to track in a purpose driven decision making framework? We want to account for “why”, “what” and “how”:

Problem

Why does it matter to our users?

Impact

What do we want to achieve?

Metrics

What does success look like?

Skills

What skills do we need to hit metrics?

Path

How do we plan to achieve impact?

A purpose driven decision making framework should help the Business and Product Development Teams better manage the bumpy road of continuous improvement and continuous learning. It offers additional clarity as to why decisions are being made and what requires further clarification. It also helps Business understand if the highest business value is always being delivered.

If we refer back to the previous scenarios, we now have a framework to guide conversations:

• Business wants to stop product development because market is underperforming

Impact:No longer supported by business

• Business wants to understand why date was missed and wants a new forecast

Path:Why did we miss desired deadline?

• Development team needs more headcount

Skills: We have learned something new and need a new skill set

• Some team members are moved to another Development team unexpectedly

Metrics:There is no further business case to improve KPIs

Working through this purpose driven framework is an ongoing activity. It is expected that some items will evolve as the business adapts to change. For example, one metric may be swapped by another one based on outcome from various A/B testing efforts.

Would love to hear about other purpose driven Product development frameworks you have used.