Business growth

“My advice would be to spend less time on finance, spend less time in the conference rooms, less time on PowerPoint, and more time on just trying to make your product as amazing as possible.” - Elon Musk

Asking questions about the value a product creates and the problems it solves—or doesn’t solve—is the fastest way to make products as amazing as possible. When people understand the “why,” they can better contribute to the “what.”

Successful companies differ from others through a culture of ownership, resulting in higher levels of autonomy, empowerment, and responsibility. This opens up the possibility of employing the scientific method—conducting experiments and analyzing data—to enable a far faster method of learning than previously possible. ¹

What it feels like

Solving real problems

Our team always keeps business growth in mind when we develop our product.
We make sure to understand how our product is useful and what problems it solves.
We have a strong culture of ownership, autonomy, and empowerment, encouraging us to explore different solutions.
We actively negotiate outcomes with product leadership, ensuring our work aligns with broader business objectives.

Ignoring the why

Our team focuses on finishing tasks without really thinking about how our work helps the business grow.
We don’t spend much time talking about why we’re doing what we’re doing or the benefits our product offers.
We often add features without validating if they’re actually useful for our users or if they help achieve our business goals.
We set our own outcomes without knowing what the business is trying to achieve, or we are asked to deliver outputs with no regard for outcomes.

Strategies

Understand the difference between outputs and outcomes

Outputs

Outputs are the direct results of tasks or activities. In the context of product development, outputs can include new features, updates, software releases, or any tangible deliverable produced by the team.

Outputs are quantifiable and easy to measure. They represent the volume of work done, such as the number of features deployed or the completion of project milestones.

By focusing on outputs, teams can appear to be busy, while not actually contributing to business growth.

Outcomes

Outcomes are the changes or benefits realized as a result of the outputs. They reflect the value created for the business or its customers Outcomes can include increased customer satisfaction, higher sales, market growth, or improved operational efficiency.

Outcomes are qualitative and sometimes quantitative, focusing on the effectiveness and real-world impact of outputs. They are often measured through key performance indicators (KPIs), customer feedback, and other metrics that indicate success beyond mere task completion.

By focusing on outcomes, organizations can avoid work on outputs that do not contribute to meaningful business growth.

Outcomes are the result of two-way negotiation²

The focus of the team’s efforts should be on the results they achieve, with an emphasis on the quality of these results rather than the volume of tasks completed.

Negotiating the desired outcomes should be a collaborative process between the product team and the company’s product leadership (such as the Chief Product Officer or a Client Representative).

If you are being asked to deliver outputs with no regard for outcomes, ask your leader and stakeholders more questions to understand who you’re building for and what the desired outcome is going to be.

If your team is setting their own outcome with no input from the product leader, ask your leader and stakeholders more questions to understand what the business is trying to achieve.

If your team is already negotiating outcomes with your product leader, congratulations!

Define hypotheses³

Hypothesis-driven development complements user stories by focusing on business outcomes instead of the user’s goals.

To articulate a hypothesis, the framework can be structured as follows:

Capability statement - the feature you want to implement.
Expected outcome - what you believe will happen as a direct result of the feature, such as higher sales or increased user engagement.
Measurable signal - how you plan to measure the impact.

We believe this capability will result in this outcome. We will know we have succeeded when we see a measurable signal.

Measure impact

Contributing to business growth requires a clear understanding of your efforts’ impact. This involves establishing key performance indicators (KPIs) and metrics that directly correlate with the desired outcomes.

Use lightweight change approval processes

Changes to code, infrastructure, and databases should be reviewed using lightweight processes such as code reviews or paired programming.

Accelerate⁴ research shows that external approval processes (each change reviewed by someone outside the team) negatively affect lead time, deployment frequency, and restore time, with no impact on change fail rate.

Some standards like PCI DSS require segregation of duties for authoring and approving of changes. This does not require the use of a separate external review board. We recommend processes where a team member not involved in authoring the change conducts the code review and approves the change.

Encourage innovation⁴

Teams should have the freedom to experiment with multiple approaches to achieve better outcomes. This means that multiple solutions to the same problem are tried. This approach requires a supportive culture that views failures and setbacks not as final, but as valuable learning opportunities that contribute to the collective knowledge and improvement of the team.

Finding the best solution often doesn’t require multiple solutions to be coded. Instead, the emphasis should be on ideation, prototyping, and validation before committing significant resources to development.