Sign in Subscribe
Product Engineer

Outcome Orientation

Dohyeon Kim

• 8 min read

Product Engineer Series

After gaining a deep understanding of user desires, needs, and pain points, you'll have a better idea of potential opportunities. Like all opportunities in life, each one comes with an opportunity cost. By choosing one opportunity, you're forgoing the potential returns of pursuing others. This raises a crucial question: what opportunity should you pursue first?

Traditionally, this decision came from above—business leaders—and engineers were not part of the decision-making process. Discovery happened once a year at budget meetings, where projects were assigned to engineering teams with fixed timelines and budgets. There were lengthy waterfall processes to refine requirements. Since software development is unpredictable, projects were often delayed or not delivered at all. Or worse, teams only learned lessons long after shipping the product, when users showed little excitement.

The Agile movement emerged around 2001 to solve these execution inefficiencies. A group of engineers, frustrated with these problems, proposed several principles: shorter development cycles with quicker feedback, sustainable yet continuously improving processes, and an emphasis on flexibility and simplicity. As a result, building software became more predictable and less risky than before.

The Lean Startup Method

However, Agile alone didn't solve a fundamental problem: what if the team is building a feature that nobody wants? Eric Ries describes a new approach to address this issue in his book, The Lean Startup:

Because startups often accidentally build something nobody wants, it doesn't matter much if they do it on time and on budget. The goal of a startup is to figure out the right things to build—the thing customers want and will pay for—as quickly as possible.

This highlights two important concepts:

1. User value: the thing customers want.

Successful products solve user problems. Eric explains that his team initially assumed users would want to integrate the product with their existing instant messaging platforms. As a result, the engineering team focused on building interoperability features to connect different messaging services. Six months later, however, they discovered that users were not interested in bringing over their existing friends; instead, they wanted to meet new people within the exciting 3D avatar world.

2. Business value: the thing customers will pay for.

Successful products should sustain your business. While some engineers might feel uncomfortable discussing this aspect, without a sustainable business model, you can't provide user value in the long term. The challenge arises when companies leverage or manipulate user behavior to maximize profit. In the book Hooked, Nir Eyal explains how social media companies design their products to be habit-forming, leading users to spend more time than intended while generating advertising revenue. This demonstrates the delicate balance between creating business value and maintaining ethical user engagement.

Outcome Orientation

Outcome-oriented engineers think in terms of outcomes rather than outputs. Instead of defining success by the number of features released (or lines of code written), they measure success by how much user or business value their code creates.

Outcome orientation has been guiding business leaders for decades. Peter Drucker wrote extensively about its benefits, Andy Grove implemented the practice at Intel and documented it in High Output Management, and John Doerr, along with Google, popularized Objectives and Key Results (OKRs) as described in Measure What Matters.

Teresa Torres puts it eloquently in her book, Continuous Discovery Habits:

When we manage by outcomes, we give our teams the autonomy, responsibility, and ownership to chart their own path. Instead of asking them to deliver a fixed roadmap full of features by a specific date in time, we are asking them to solve a customer problem or to address a business need.

Types of Outcomes

Different types of outcomes exist, and product teams need to focus on product outcomes rather than business outcomes.

A business outcome measures how well the business is performing. These outcomes often relate to financial metrics (revenue, costs) or market share. While they're crucial for measuring business success, they're not ideal targets for product teams. Revenue increases can be attributed to many factors—you can't isolate your new feature's impact when marketing, support, and other teams are all contributing. Sometimes your product team has minimal control over certain metrics due to their specific responsibilities.

A product outcome measures how well the product supports business outcomes. Unlike business outcomes, product teams have direct control over these metrics. If your business outcome is increasing revenue, your mobile app team might focus on improving shopping cart conversion rates or reducing the time it takes for users to complete a purchase. Unlike business outcomes, you can observe the impact of these changes quickly—in days rather than months.

Good Product Outcomes

A good product outcome emerges from the intersection of user values and business values. For this reason, it should be a two-way negotiation between business leaders (CEO, VP of Product, etc.) and the product team (Product Manager, Product Designer, Product Engineers). Business leaders are well-positioned to bring business needs based on their role and perspective. Product teams are better positioned to bring user values, since they work closely with users and the product.

Who should take the lead in deciding product outcomes? The answer varies depending on your situation and team size. I've experienced both extremes—when the product team had complete freedom to suggest what they wanted to pursue, and when business leaders set narrow guardrails. In my experience, it works best when the product team receives a relatively narrow business outcome but has the freedom to suggest product outcomes to improve that area. However, this can vary based on your specific context.

Benefits of Aligned Product Outcomes

Successful product engineers are well-aligned with product outcomes that bring user and business value. They understand what problem to solve, why it's important, and how to measure success when they make changes. This alignment brings the following benefits:

1. It gives the product team autonomy

Once you have a clear product outcome, it increases the possibility of shipping engineer-led ideas.

I've often seen leaders encourage engineers to come up with ideas. However, these ideas frequently end up buried by other features in the roadmap and never get implemented. After several similar experiences, engineers stop bringing up their ideas. Outcome orientation can help this situation in two ways:

  • For engineers: It helps them filter their broad ideas down to those that directly bring user or business value. If the team is aware of a complicated user sign-up process, your idea about reducing it by half using a new smart login solution becomes an obvious priority. This leads to good outcomes with relatively small effort, since engineers are closest to the technology and know which adjustments will make quick and sustainable changes.
  • For leadership and product managers: Having a clear outcome can reduce planned items in the roadmap. This makes it more likely there will be room for engineer-led ideas to actually get implemented.

2. It makes the product × design × engineering decision process easier

Consider a product team discussing whether to keep or remove an onboarding animation screen. Without a clear outcome, such decisions often come down to personal preferences—perhaps a designer appreciates the aesthetic value of the animation, while engineers raise concerns about the increased app size. These discussions can become emotional rather than objective.

However, with a clear outcome—such as increasing user conversion from start to finish—the decision-making process becomes more straightforward. The team can run A/B experiments comparing versions with and without the intro animation. If the data shows that removing the animation leads to faster completion times and higher conversion rates, the path forward becomes clear. Starting with a small experiment (say, 2% of users) makes it easier to validate the change before full deployment. When teams have concrete data aligned with their target outcomes, decisions become objective rather than subjective.

Balance Between Discovery and Delivery

Engineers should be involved in the early stages of product development (discovery) and contribute their perspectives in addition to handling delivery. The best ideas often come from engineers because they are closest to the technology, and their deep understanding puts them in a strong position to consider engineering implications.

However, balancing both discovery and delivery isn't always easy. In my early days, I often felt that discovery meetings were a waste of time—I had so much to do! (To be fair, everyone does.) I would think, "I don't have time for this." or "I've spent all this time with product and design, and now I barely have time to actually implement it." But I started to see the importance of this involvement when I saw my project become irrelevant. I had put literally months of hard work into this project. I had clean structure and all the unit tests. But none of that mattered anymore, since the product I invested so much in was something no one wanted to use.

I initially blamed others on the team, but it took time to realize that wasn't fair, since there were many opportunities where I could have contributed but didn't. I could have brought up points like:

  • "There are easier ways to solve the same problem if we adjust just this or that."
  • "I know we've been working on improving this key result, and Apple just announced a new OS feature that could help us move the needle with minimal investment."
  • "In this requirements document, we want to update this section. However, updating only this part of the app is actually more difficult without also updating other sections that perform the same function. Should we update them all together? What would be the implications for user experience or business value?"

It's important to establish a sustainable schedule between discovery and delivery, though. It's difficult to context-switch between discovery and delivery since you're using different parts of your brain. I found setting aside discovery days from delivery days very helpful. If your team is on a 2-week cycle, discovery days could be after the middle of the sprint when your biggest unknowns for the sprint are mostly cleared up. Also, having discovery days every 2 weeks is helpful to prep your backlog in advance. You don't want to be interrupted by a discovery meeting to prep for the next sprint in the middle of your deep engineering work. Having a recurring time slot allows the team to have enough discovery in advance and helps everyone plan for it.

Alternatively, you can do a 6-week full focus on a single solution as described in the book Shape Up. At Basecamp, they shape the work (discovery) in advance. Six weeks is long enough to build something meaningful start to finish, and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. Having set cycles means you don't have to worry about switching between discovery and delivery in the middle of the cycle. Practically speaking, you might still do both at the end of a current cycle and the beginning of an upcoming one, but you still get the benefit of a full focus on deep work in the middle.

Tool: Experimentation

Using experimentation is a very handy tool to bring user and business value with reduced risk. I've shared how you could use Feature Flagging (a type of experimentation) in this article: Effective Feature Flags with Kotlin Multiplatform & Firebase.

Conclusion

Outcome orientation transforms how product engineers approach their work, shifting the focus from output to impact. By understanding and aligning with clear product outcomes, engineers become more effective contributors to both user value and business success. This alignment enables better decision-making, increases team autonomy, and creates space for innovation.

As the software industry continues to evolve, outcome-oriented product engineers will play an increasingly crucial role in building products that not only work well technically but also deliver meaningful value to users and businesses. By embracing this mindset, engineers can move beyond being just implementers to become true drivers of product success.

Further Reading

Disclaimer: This post contains affiliate links. This means I may earn a commission should you chose to sign up for a program or make a purchase using my link.