Our company was moving from a single development team/single roadmap structure to a pod structure where individual pod leaders, namely the product lead, are responsible for making prioritization and build decisions that align with our overarching product strategy and company objectives. I wanted to build a framework that product leads could refer back to when making their own product roadmapping and prioritization decisions, so I worked with our Head of Engineering to develop this framework.

We recently decided to prioritize and build a very complex report generation feature. This requires extensive engineering time and effort but when looking at the value to the customer and company using this framework we realized it made sense.

We hypothesized that the feature will help our customers on the speed, scale and satisfaction axes, as it takes an existing workflow that they are already doing today that is very time consuming, error prone and non-standardized, and makes far more efficient and scalable. On the company objectives front, we hypothesized that it would help with all 3 of our core product objectives (activation, adoption and engagement) as well as substantially move the needle on our top level org objective, as compared to other projects that we could work on.

Often times a project will get deprioritized or at least descoped if the engineering effort is too high or if our confidence level is too low. Before we go deep into product design and before we ever write a single line of code, we will write a product brief that describes the feature and share it with our engineering leads who will provide a high level estimate of cost. Often times the cost of the feature as described is larger than we want to take on, so we will descope the feature to make it less functionality-rich, but other times if the feature requires both significant engineering effort and we don't have high confidence that it will help us achieve our objectives we will abandon it.

Our Head of Engineering and I jointly presented this framework to the entire product development org of PMs, engineers and product designers. Our goal was to introduce the framework and facilitate a discussion and debate over key concepts if necessary. I think it was very well received because often times product roadmapping can seem like a black box to those not intimately involved and this framework built confidence that we have a structured, systematized process around this.

We spend no more than a few hours completing this exercise for each product. This should be informed by a few user/customer/subject matter expert conversations, conversations with engineering, and conversations with any required legal or compliance partners. This helps to codify how we develop products.

Dave St. Geme

This document outlines how we approach product development at Luminary to ensure that we are building products that create positive outcomes for our customers and our company.

Product Development Process at Luminary

Sign up to see more