Our Thinking

Principles of Innovative Product Success: Part 1

Start with Why

At Rocket Wagon, we work on complex problems that span from personal healthcare to education, sustainable energy to retail and much more. We design and build digital and connected products intended to disrupt industries and move markets. We take complicated constraints and turning them into empowering opportunities. 

To consistently deliver successful innovative products for our clients, we have built a scalable product practice that involves the entire company and always starts with one word: why?

Start with Why

Avoid the feature factory mentality with a simple inspiring question.

We believe that the first step in building best practices is to avoid reinventing the wheel; it’s far more effective to stand on the shoulders of thought leaders. To this end, we try to approach every challenge with Simon Sinek’s resounding bit of simplicity: Start With Why. For our team, this is the practice of uncovering, understanding or reminding ourselves why we are working on something. The concepts of Start With Why apply daily to our internal workstreams and methods, but in this post we’ll discuss how we enable and encourage our clients to find their why and build around it. 

From ‘Share the Golden Circle’ by Simon Sinek

When our clients propose a new problem set, we always start with the same question. The goal of asking “Why?” is to inspire our clients to change or build with purpose. This “purpose” should not be to release a product or feature. Instead, the “purpose” should be to deliver meaningful ROI and inspire our users to loyalty.

Note: We can often determine what is meaningful by examining our team or business OKRs. We’ll address OKRs in a little bit.

One core mission for our Product Managers is to maintain stakeholder focus on outcomes over outputs. If we release a slew of features on time that return very little — or even worse, are not measurable — they are far less valuable than a single release that can be measured accurately and further optimized.

If we understand why we are building a thing for our users, then we can determine what we want to build and subsequently how we will go about building and measuring that thing. In other words, we can only know what it is we want to measure when we can clearly define why we are measuring it at all.

“Teams today are all too often feature factories, with little regard for whether or not the features actually solve the underlying business problems.  Progress is measured by output and not outcome.” 

Marty Cagan, SVPG

This feels obvious, right? In many cases, an “obvious” solution is not a universal truth. In the standard Product (and consulting) mechanism, stakeholders vying for visibility oftentimes become emotionally attached to their product or feature deliverable. They will tie their success to the delivery of a product that is reasonably within budget and on time. Anything else will look like varying shades of failure, and the user reaction or adoption is relegated to secondary importance. 

To address this, we keep our stakeholders inspired by the “Why” at all times. By inspiring others we establish a following. Whether they’re clients, employees or users, excited followers are the most loyal. Backed by loyalty and a shared understanding, we have the capacity to deliver effective change. 

To summarize, “Why” helps us with three key goals:

  1. Understand the value we are working to deliver for our users
  2. Determine if we actually delivered that value
  3. Motivate, captivate and inspire our stakeholders
Once we have helped our teams establish the why, it’s critical that we build an actionable framework around it. This is where the OKRs come in.

If you’re unfamiliar with OKRs, take a few minutes to read this article explaining the basics of how they work.

Stay Connected with OKRs

Objectives and Key Results shouldn't be scary - they should inspire us to shoot for the stars.

Let’s face facts: OKRs can be pretty daunting.  By nature, they should be nearly impossible to hit 100% because they are intended to be aspirational. For example, if I want to decrease user churn on my mobile app, I might set an Objective of “Reduce Churn 85% by the start of next quarter”. This seems borderline unreasonable, as there’s almost no way I can affect such a massive change in a key metric in this short a period.

[Note: A key here is being quantitative, as “..,qualitative goals tend to under-represent our capabilities because the solution tends to be the lowest common denominator”.]

A truly unattainable goal may seem like a counter-intuitive way to track success of your product – especially when working with stakeholders. We don’t believe that to be true. In fact, we believe that they actually inspire our stakeholders by reminding them that success is an iterative process. As a result, the OKRs we build always ladder up to our “Why”, with room to measure, ideate and optimize for success.


Let’s take a look at our initial example of “Reduce churn 85% by the start of next quarter”. Here’s how we might deliver this OKR to the client:

  • Objective:  Reduce Churn 85% by the end of next quarter
    • Key Result: Maintain 10% reduction in churn week-over-week as seen in Google Analytics.
    • Key Result: Contact and record a statistically significant percentage of all churned users each month to determine the top reasons for leaving.
    • Key Result: Deliver one additional loyalty-based feature that is adopted by 25% of users in the first week.

Why: Our user count is not growing as quickly as it should be given the amount of investment we’ve added on the acquisition side of the business. This represents a potential threat to revenue based ROI.  We need to supplement this investment with a retention effort that will help stem the losses and hopefully provide some important insights into how we can continue to build a valuable product for our users.

What: A program designed to understand user churn that helps define the business and user requirements for future feature development. As we see the highest retention with our loyalty program users, let’s continue to invest there to see if an additional feature will be attractive to potential loyalty users. 

How:  Contact churned users by email, offer them an incentive for filling out a survey related to their leaving the app. Employ statistically sound methodology for examining the data. Further investigation is needed for the loyalty feature. **

It’s critically important that there is a conversation between the Product Manager and our client stakeholders regarding OKRs, before the Product Development Cycle kicks off. It is the job of the Product Manager to ensure that the the OKR accurately represents the business goals, and that everybody involved agrees with the aspirational goal and roadmap to achieve it. 

In any event, you’ll need a meeting whereby you can establish the why and discuss the OKRs. Product governance committees are a great way to do this.


There does not (and should not) be a solution that is pulled from OKRs; that is the job of the design and development team to determine. 

Product Governance Committees

Keep your key stakeholders connected to the core vision.

At the start of every quarter, our Product Managers interface with our client’s Executive team to build a prioritized roadmap for the upcoming 90 days. This “Steering Committee” serves as an assessment of the shared Why alignment, as well as a discussion about the company-wide OKRs. 

Our team prepares for the Steering Committee meeting by collecting a high-level assessment of the top Backlog features or Technical Debt from the Solutions Architect or Team Tech Leads. We also make every effort to provide insights into the predicted outcomes and market impact based on a number of different metrics. Coming in to the Steering Committee meeting with this perspective is critical in helping the Executive team to understand how trade-offs will impact their outcomes. All of these decisions will inform the ongoing prioritization at a micro-level between the PM and the daily stakeholders, or the “Working Committee”. 


Every two weeks, the Product Manager will meet with the Working Committee team to discuss this ongoing prioritization. This maintains the fidelity of an iterative design + development process by offering the opportunity for feedback and optimization. We make sure to always maintain a perspective on the “Why” and ensure all parties are continually aligned in Working Committees. During and after releases, we discuss what outcomes we’re tracking, and discuss any available stats that will help inform our ongoing exploration. 

Ongoing Exploration

In our next post, we’ll explore how we take a) the “why”, b) the OKRs, and c) the insights gained from outcomes to create a best-in-class, modern development cycle. 

Give us your hard problems

Build a reputation for innovation, and embrace the full power of your future with Rocket Wagon.

Let's Talk