Aligning Teams With Outcomes - A Product Application

By Paul Blay October 13, 2025

From experience I know that great ideas are only as valuable as their applications in the real world.

I’ve used OKRs and Outcome framing for quite a while, so it’s about time to showcase a real world example - what it did for us and what we learned.

I’ll present this in the classic STAR format like I’m trying to answer an interview question… because that’s what I’ve been spending time doing recently. 😃

Situation

I’m being moved into the NPI (New Product Introductions) group as the lead. The group consists of three teams of engineers, with product owners and QA spread across the teams.

The group just came out of a failed multi-year effort to develop a new product and were suffering from burnout.

Marketing were seen as the enemy, teams had little autonomy and complained of regularly being asked to perform miracles, releases were rare and difficult. All focus recently had been on generating demos for trade shows to show off a new platform, resulting in demo-ware that was had to extend and customers couldn’t actually use.

Work was fed into the team via dictate, partly due to a lack of ownership over a new plan.

Here’s the odd thing - the teams had some of the best engineers in the building. The marketing representation was also very knowledgable and customer focussed. This was absolutely a fixable state.

Task

There were a lot of actions taken to try and get things into shape, including: Organisational design, role clarification, building relationships, adapting process, etc - but here I’m just going to detail the switch from task focus to outcome focus.

The task at hand was to define an objective considering the customer needs, technology stack available, group capability and RoI. Then find a low cost way to measure our progress towards this objective.

Action

Consulting and working alongside marketing, product, engineering and the wider business, I formulated a strategy and initial OKR to win business with our new SOC platform.

The Strategy

Along with marketing I built a strategic approach, using a framework from Good Strategy/Bad Strategy by Richard P. Rumelt.


Diagnosis:

    Customers can't differentiate with
    our products, want to extend to smart/connected solutions
    and we want to quickly showcase new capability
    without compromising on practice.​

Guiding Policy:

    Provide an SDK for customers to
    differentiate and extend existing functionality.

The SDK would allow customers (or our FAEs) to deploy their own simple applications to our product in order to differentiate, using capability and expertise already existing within the engineering teams - employing cloud infrastructure from previous projects to manage app deployment during development.

The first action of which was to create the OKR.


The OKR

Here’s what we came up with: Objective: Customer Design-in for our new SoC

KR1: Customer application prototype deployments per week​ from 0 to 20

KR2: Number of customers actively deploying​ per week from 0 to 3

KR3: Monthly customers requested meetings with us on integrating our solution from 0 to 6


Testing The Maturity

More “putting ideas to real world use” here. How does our new OKR stack up against the criteria in the OKR Scorecard?

Objective

FactorVoted Average Score
Is Inspiring to me5
Represents an important impact7
I understand why10
Sum22



Multipliers

FactorValueMultiplier
Represents value for the businessDirect Value2
DefinesWhere1


Result: 22 x 2 x 1 = 44/60

Not too bad.

KRs

KR1: Customer application prototype deployments per week​ from 0 to 20

FactorVoted Average Score
Is “realised” as opposed to “delivered”10
“I would consider reaching this as a significant aspect of the objective completed”5
Sum15



Multipliers

FactorValueMultiplier
Is numericalYes2
MeasurabilityCould be measured with some work1
Represents a change in customer behaviourYes2
Likely distribution of movement over OKR lifetimeEven distribution2
Multiple paths to achievementYes1


Result: 15 x 2 x 1 x 2 x 2 x 1 = 120/160


KR2: Number of customers actively deploying​ per week from 0 to 3

FactorVoted Average Score
Is “realised” as opposed to “delivered”10
“I would consider reaching this as a significant aspect of the objective completed”6
Sum16



Multipliers

FactorValueMultiplier
Is numericalYes2
MeasurabilityCould be measured with some work1
Represents a change in customer behaviourYes2
Likely distribution of movement over OKR lifetimeEven distribution2
Multiple paths to achievementYes1


Result: 16 x 2 x 1 x 2 x 2 x 1 = 126/160


KR3: Monthly customers requested meetings with us on integrating our solution from 0 to 6

FactorVoted Average Score
Is “realised” as opposed to “delivered”10
“I would consider reaching this as a significant aspect of the objective completed”5
Sum15



Multipliers

FactorValueMultiplier
Is numericalYes2
MeasurabilityIs measurable now2
Represents a change in customer behaviourYes2
Likely distribution of movement over OKR lifetimeFront/back loaded0.5
Multiple paths to achievementYes1


Result: 15 x 2 x 2 x 2 x 0.5 x 1 = 60/160

Result

The really big differences from using an outcome focus were:

1. More engagement between engineering and marketing

If only one customer is actively downloading apps and we want to increase that number, the discussion becomes a collaborative one. We could run a marketing campaign, engage FAEs with better demonstration tooling, deliver a feature that a particular customer is asking for.

The difference in how separate functions in the organisation interacted was the biggest result from my perspective. We’d taken a huge step towards solving the us/them mindset between internal functions.

2. Creativity Unleashed

One teams were aware of the customer behaviour changes we were looking for, new ideas came out of the wood work. I recall members of the team asking to travel to customer locations to help teach them what they could do with our product.

Another idea was to focus trade shows on the ability to quickly switch use cases, rather than show just one flashy demo with it all.

3. The SDK was the product

Marketing were able to spin up quick demos using light weight applications and the engineering team build a feeling of ownership and care around the quality of the SDK.


All in all, I feel like this was a success story and I’m incredibly proud of what we achieved.

I hope this story can help you with your challenges in some way.