Unleashing Outcomes for Product Management

Welcome & Introductions

Kate Fuchs | 00:00–02:11
Well, let’s go ahead and get going. Thank you all for joining in and for sharing. It’s always fun to see you — it’s one of the perks of doing these virtual webinars, having that global community around product management. It’s just fun to see. So thank you for sharing, and welcome. We appreciate you taking an hour of your day. This is a really great webinar I’m thrilled to moderate and share with you some stories and expertise on unleashing outcomes.

This is something you’ve probably heard of — the feature factory. We’re living it. We’re used to cranking out features in product management. But does it move the needle? Outcome-driven product management is where we want to move to.

You’ll see our Freddie Mercury here a few times. I’m sorry — it’s just going to be stuck in your head. That’s part of today; you’ll have some Queen in your head, which isn’t the worst thing. So let’s get some introductions going.

Kate Fuchs | 02:11–02:18
So we’ve got a couple of folks I’ll let introduce themselves. Joe, you want to say hey?

Joe Ghali | 02:18–02:34
Hi everyone. My name is Joe Ghali. I live in Milwaukee, Wisconsin. I’ve been in the product management space for about 20 years. I’m a principal consultant and trainer at the Productside.

Elad Simon | 02:34–02:54
Hi everybody. I’m Elad Simon. I’m the co-founder and CEO of Craft.io. I’m based out of Tel Aviv, Israel. I’ve been in product management for about, I don’t know, 15 or 20 years or so. And as I said, I lead Craft.io, which is a product management platform.

Kate Fuchs | 02:54–03:12
Perfect, thank you. And I’m Kate Fuchs. I’m a product manager at Productside as well. I’ve been in product management for about seven years now, and I’m going to be moderating today. So welcome.

Who We Are — Productside

Kate Fuchs | 03:12–03:46
So just a quick look at who we are at the Productside — we’re here to help transform your product management team and organization and move away from that feature factory. We want to move into outcomes over outputs, and we’re going to talk about that today.

It’s something we hear a lot from our clients: “We want to make sure what we’re working on day-to-day is actually moving our business outcomes forward.” That is who Productside is. Joe is one of our principal consultants and trainers, and we’ve got a great team to help transform your groups.

Who We Are — Craft.io

Elad Simon | 03:46–04:32
Thanks for that, Kate. Craft.io is a product management platform, and we help you transform your team when it comes to product management — but through tooling. We help you get away from the hodge-podge of spreadsheets, Jira, PowerPoint decks, Google Docs, Confluence, etc., and into a single place where you can manage all your work and have a single source of truth for product management.

A place you can call home.

Housekeeping & Participation

Kate Fuchs | 04:32–05:20
A little housekeeping — we love the chat and the Q&A. This is for you, and we’d love to answer your questions later in the webinar. You’ll see the Q&A feature at the bottom of Zoom, but you can also drop questions into the chat.

We are recording. If you want to share this with a colleague or your boss, we’ll send out the recording via email.

There are also LinkedIn links in the chat — follow Craft.io and Productside. We’ve got great content, discussions, videos, and all kinds of product-management goodness.

Setting the Stage for Outcomes

Kate Fuchs | 05:20–05:32
All right. Let’s go ahead and dive in at this point. I’m going to pass it off to Joe and let’s get rolling.

Joe Ghali | 05:32–05:48
All right — so we’re going to start out by talking about the currency of product management. We’re talking about unleashing outcomes and breaking free from the feature factory.

The Feature Factory Reality

Joe Ghali | 05:48–06:41
How many of us on this call today feel like, as product leaders, product managers, maybe even product owners or part of a product team, that in our day-to-day grind we work in a feature factory? It’s probably one of the biggest challenges we have in the product management space.

We have stakeholders, executives, VPs — they look at product management as a discipline for popping out, churning out features. Kate and I were talking about this image the other day — we’re big fans of the UX unicorn. I know a few companies I’ve worked with that could use several of those unicorns.

But really, how many of us feel like our success is measured not by outcomes, but by:
“How many user stories did we deliver?”
“How many features did we release?”

What we’re trying to do — as coaches, consultants, trainers — is help companies get out of this rut. We want to get out of that mentality that the more we ship, the better. More does not equal better.

Managed by Outputs vs. Outcomes

Joe Ghali | 06:41–07:39
The reality is: we are often managed by outputs.

Just the other day, I was talking to someone, and I asked, “Hey, how was last quarter?” And this particular product leader said, “Oh, I’m really excited because we released on time.”

So I asked, “Okay, great — but what was the impact?”

And then it came out:
They had bugs.
They had frustrated customers.
They didn’t achieve the result they intended.
The release didn’t produce the intended business impact.

So I kept peeling back:
“Well, what outcome were you trying to achieve?”

Their answer was essentially an internal IT product where they hoped to streamline processes and gain efficiencies.

This is the challenge. Roadmaps become Gantt charts: lists of features with specific dates. Success becomes “on time, on budget” rather than “did we achieve the outcome?”

We must get out of that mindset.

Poll #1 – Are You Measured on Features?

Kate Fuchs | 07:39–08:12
Okay, we’re going to open up our first poll. We’re curious:
How many of you feel your success is based on the number of features or user stories you deliver?

Joe Ghali Ghali | 08:12–08:20
We see some really great questions coming into the chat already.

Kate Fuchs | 08:20–08:39
Yes, lots of chatter in the chat — keep it coming! And thank you to the UX Unicorn who announced themselves. That made our day.

Kate Fuchs | 08:39–09:07
All right, responses are coming in. I’ll give it a few more seconds. This is a great question and we’ll talk more about roadmaps soon.

Okay — counting down… three, two, one. Let’s share the results.

Kate Fuchs | 09:07–09:23
It looks like many of us resonate with what we’re saying here. We’ve got a mix of “yes,” “sometimes,” and surprisingly some “never” — which is impressive. I want to hear your stories!

Joe Ghali | 09:23–09:42
This is actually better than what I typically see. Twenty-three percent saying “yes” outright? That’s better than average. I’m usually a glass-half-full guy, but that’s still higher than expected.

Elad Simon | 09:42–10:07
I’m encouraged to see that many of you say “sometimes.” I’d be worried if it were 100% “yes.” Delivery is a part of the product manager’s job — you can be amazing at discovery and strategy, but if nothing ever ships, that’s also a problem. It’s a balancing act.

How to Break Free from the Feature Factory

Joe Ghali | 10:07–10:51
So let’s talk about breaking free.

Earlier, someone asked about business outcomes. For example, I worked with an organization where one of their business outcomes was platform stability — uptime. That’s a valid outcome.

Outcomes can be about:

• Customer experience
• Revenue
• Efficiency
• Reliability
• Compliance

Your objective should NOT be: “Release on October 12.”
Your objective should be: “Increase platform uptime to 99.99%.”

I’ll give you a quick story. Early in my career, in FinTech, I was launching a major website redesign. I told everyone: “We’re going live in October.” The night before launch, we did load testing — and we were not ready. We were up until 3 AM trying to fix things.

The next morning my leader, Tim, told me:
“In a year, no one will remember when you launched — but they will remember the experience.”

That lesson changed the way I think about outcomes forever.

Business Outcomes → Product Outcomes → Outputs

Joe Ghali | 10:51–11:41
So how do we get to outcomes?

Three definitions we should level-set:

Business Outcome
A measurable company-level goal. Changes annually. Big-picture.

Product Outcome
A behavior change in your user that results from changes to the product.

Example: Remote check deposit

• The feature is the output.
• The product outcome is that customers stop going to branches and instead deposit checks via the app.
• The business outcome is reduced operational costs and faster funds availability.

Output
The features and capabilities we ship.

This middle one — product outcomes — is where most companies struggle.

Elad Simon | 11:41–12:24
Yes — and it’s critical. Business outcomes are too high-level for a product team to own. Product outcomes translate strategy into something you can actually deliver and measure. It’s a balancing act: you must listen to customers, but also stay aligned with the company strategy.

Shipping features no one uses? That’s not success. And by the way — 80% of features in public SaaS products are never used.

That’s the output trap in one statistic.

Outputs vs. Outcomes in Practice

Joe Ghali | 12:24–13:10
Before we go to the next slide, there’s a really good question from an attendee about tying product outcomes to customer problems. The way I look at it: product outcomes should be tied to customer problems, user problems, or workflow inefficiencies.

How we achieve the business outcome is by identifying the biggest problems to solve. If we solve these problems — or address these gaps — then yes, we’re moving the business outcome.

How we solve those user problems is through a collection of features, not just one shiny thing.

Elad Simon | 13:10–13:53
Yes, and remember: product management is a balancing act. Sometimes customer feedback is right — sometimes it represents a noisy minority. You may get a flood of input about a feature that shouldn’t even exist.

If something misaligns with strategy, the right outcome may be to retire the feature, not invest in it.

Our job is to weigh strategy AND customer feedback — not blindly chase either.

Capabilities → Product Outcomes → Business Outcomes

Joe Ghali | 13:53–14:23
Now this slide builds on the previous visual. Capabilities we deliver enable product outcomes. Product outcomes enable business outcomes.

In our training, we cover the nuance between:

• Product KPIs: Are users finding value?
• Behavior Change: Are they actually doing something differently?

It’s that behavior change that signals a product outcome.

Joe Ghali | 14:23–14:35
Let’s move to what not to do — this is where many of us have lived.

What NOT to Do — Output-Focused Thinking

Joe Ghali | 14:35–15:29
Many of us have lived in this space. Here’s the classic output-driven OKR:

Objective: New app UI
Success Metrics:

• Add this feature
• Launch by this date
• Number of downloads

None of these are outcomes. They are activities.

Contrast that with outcome-focused thinking:

Objective: Increase reoccurring revenue
Product Outcome: Improve airport passenger throughput
Success Metrics:

• Reduce time in security lines
• Reduce check-in wait times
• Increase usage of mobile boarding
• Improve customer satisfaction scores

Each of these success metrics ties to a specific user problem, persona, or scenario.

Outputs support outcomes — not the other way around.

Poll #2 – When a Feature Is Created, Is It Tied to a Product Outcome?

Kate Fuchs | 15:29–15:48
All right — let’s launch our next poll.
When a feature is created, is it tied to a product outcome?

Yes, no, sometimes.

Kate Fuchs | 15:48–16:11
I see lots of chatter in the chat — love it. I also see many of you acknowledging resource constraints: we’re all being asked to do more with less.

Kate Fuchs | 16:11–16:33
All right, get your votes in… Three, two, one — let’s share the results.

Kate Fuchs | 16:33–16:45
Looks like most of us are “sometimes.” Joe or Elad, is that surprising?

Joe Ghali | 16:45–17:06
Honestly, 23% “yes” is better than what I typically see. I’ll take it. I’m a glass-half-full guy — or maybe 23%-full.

Elad Simon | 17:06–17:47
I’ll be more blunt:
If something doesn’t connect to a product outcome — it should not be built.

Even technical debt has an outcome. If fixing something prevents outages or enables future work — that’s an outcome.

If a feature has no expected outcome, challenge the request.
If a stakeholder can’t explain the “why,” then the answer is: don’t build it.

How to Move From Output-Driven → Outcome-Driven

Kate Fuchs | 17:47–18:10
So how do we get started? Let’s talk about practical steps.

Kate Fuchs | 18:10–18:45
One of the first things we recommend is:
Have a strategy conversation with your leader or product manager.

We have templates for this in our Playbook — including a Strategy Discussion Guide. It’s meant to help you ask:

• What are our business outcomes?
• What are our product outcomes?
• How do these drive priorities?

If you’re trying to connect outsourced dev teams or siloed squads to outcomes — this is how you anchor the conversation.

Elad Simon | 18:45–19:34
And be aware: sometimes leaders are not aligned with outcome thinking yet. That’s okay.
Your job then is to start the meta-conversation:

“We want to avoid building things that never get used.”
“We want to reduce rework.”
“We want to tie effort to ROI.”

That’s a conversation executives understand instantly.

Outcome conversations reduce wasted work — that’s a bottom-line argument.

The Leader Pack & Outcome Templates

Kate Fuchs | 19:34–20:12
We’re giving you all a free Leader Pack today. It’s part of the Productside Playbook, which includes over 20 templates and tools — with instructions, examples, and guidance.

This pack is incredibly helpful for drawing that line between leadership-level strategy and the day-to-day work product teams are carrying out. We’ll drop the link in the chat so you can download it.

We’re going to walk through a couple of these templates next.

The Outcome Tree — Connecting Strategy to Execution

Kate Fuchs | 20:12–21:04
Let’s talk about the Outcome Tree. This is one of the most powerful tools we use.

The Outcome Tree helps you connect the top-level business outcomes all the way down to the features and capabilities you’re building day-to-day. We want to make sure the “leaves” — the work — connect to the “roots” — strategy.

You’ll see at the top:

• Business Outcomes
• Product Outcomes

Then under Product Outcomes, you’ll see Product Success Metrics — these are the measurable behaviors or results you expect to see when the outcome is achieved.

We also show Health Metrics — enabling work like system stability, technical debt, or architectural improvements. Health metrics matter because you don’t have a product if the system goes down.

Then we tie that to:

• Problem Statements
• Solution Hypotheses
• Capabilities / Features

This is where things fall apart in feature factories. If what you’re building cannot be connected to the problem, the product outcome, or the metric — that’s a red flag.

Joe Ghali | 21:04–21:32
Exactly. We sometimes forget the problem. This template forces us to articulate it before jumping to the solution. Who are we solving for? What’s their pain? What’s our hypothesis?

This context must come before features.

Elad Simon | 21:32–22:05
And templates like this don’t just guide your thinking — they guide the conversation with stakeholders. They help you tell the story behind your decisions.

These tools are simple, but they help you structure your thinking and avoid jumping straight to outputs.

Outcome-Based Roadmaps (Now | Next | Later)

Kate Fuchs | 22:05–23:02
Next, let’s talk about outcome-based roadmaps — specifically the Now / Next / Later format.

This creates clarity around:

• What we’re focusing on right now
• What we’re considering next
• What we might pursue later

Each item should tie directly to a product outcome and success metric.
For example:

Product Outcome: Get passengers through airport security faster
Success Metrics:

• Reduce wait times
• Increase mobile check-in
• Improve throughput efficiency

Under “Now,” you list the concrete features tied to those metrics.
Under “Next” and “Later,” things should get progressively less detailed because they’re further out.

This is how you start sequencing work — and it’s how you ensure what you’re building ties back to outcomes.

A Live Example: Craft.io’s Objective-Based Roadmap

Elad Simon | 23:02–24:05
Let me show you how this looks in Craft.io.

(Referring to shared screen)

Here’s an objective-based roadmap. Each lane is an objective (or outcome). When presenting to stakeholders, I reveal the objectives first — this automatically elevates the conversation to strategy.

Then I reveal the features or initiatives under each objective. This reinforces:

We build only what connects to an outcome.

You’ll see a lane called “Other.”
If too much work lands there?
One of two things is true:

1. You don’t have enough defined objectives — or
2. The work does not support outcomes and should be removed

This forces prioritization.

Measuring Outcomes (Post-Release)

Kate Fuchs | 24:05–24:32
We won’t spend too much time here, but it’s important.

Releasing something is not the finish line.
We must measure whether the release changed the behavior or metric we expected.

That’s why outcome-based roadmaps always tie features → metrics → outcomes.

It prevents the “launch and leave” trap.

Special Offers

Kate Fuchs | 24:32–25:10
As a reminder:

• You’re getting the Leader Pack free today — please download it.
• Craft.io is offering 20% off all plans, which is a fantastic deal.
• We have upcoming trainings, including Digital Product Management and Optimal Product Management.
• And yes — Joe himself is teaching the August 22–24 session in Wisconsin!

Q&A — Influencing Stakeholders

Kate Fuchs | 25:10–25:23
We have time for a couple questions. Here’s one:

“How do I influence strong-headed stakeholders in a legacy company?”

Joe Ghali | 25:23–25:59
Great question. It starts with empathy — understand where they’re coming from.

Then: transparency.

Bring stakeholders along in your product journey:

• Share customer insights
• Share problems
• Share data
• Share context
• Share tradeoffs

Most conflict comes from lack of information.
The more you show your thinking, the more you build trust.

Elad Simon | 25:59–26:40
Yes — and remember, stakeholders experience your entire product process in about 30 minutes of meeting time. You’ve been living it for weeks or months.

Create touchpoints.
Don’t make the reveal a surprise.
Bring them along gradually so they’re not blindsided.

Q&A — Managing Stakeholders & Organizational Realities

Kate Fuchs | 26:40–26:51
I see lots of folks in the chat expressing similar challenges. Let’s take one more:
“How do we handle product objectives that feel nebulous or uncertain?”

Joe Ghali | 26:51–27:33
This happens a lot. Many organizations set product or business objectives that feel vague — “increase customer value,” “expand market presence,” “improve efficiency.” These can feel unclear in terms of what you should build.

That’s where the Outcome Tree and Playbook templates help.
Break the objective down:

• What problem are we solving?
• For whom?
• What behavior do we want to change?
• How will we measure it?

When top-level objectives are vague, your job is to translate them into concrete product outcomes and success metrics. That translation is the real work of product management.

Elad Simon | 27:33–28:00
And remember: sometimes the objective really is uncertain. Strategy can be ambiguous. That’s okay — as product managers, part of our job is to bring clarity where there is none.

We work in ambiguity, and we make it actionable.

Q&A — Feature Requests & Sales Pressure

Kate Fuchs | 28:00–28:20
Another common theme in the chat:
“How do we handle sales-driven feature requests or customer demands?”

Joe Ghali | 28:20–29:10
This is a classic challenge. Sales teams want to close deals, and sometimes they ask for features that solve a very narrow or specialized need.

The key question is:
Does the feature support a product outcome?

If the answer is no, then you need to challenge it.

Here’s how you reframe:

“Help me understand the underlying problem. How often does it occur? Is it widespread? How does this tie into our strategic outcomes?”

If they can’t answer those questions, then you shouldn’t build it.

Elad Simon | 29:10–29:42
Yes — and sometimes the right answer is:
“That’s valid feedback… but it’s not aligned with our strategy.”

Stakeholders usually accept that answer when they understand the strategy and trust that you’re operating within it.

Outcome alignment is your protection against random feature requests.

Q&A — Tech Debt, Stability & Health Metrics

Kate Fuchs | 29:42–29:55
Another one from chat:
“What about tech debt? Is it an outcome?”

Joe Ghali | 29:55–30:22
Yes — absolutely.

Tech debt work often maps directly to business outcomes:

• system stability
• uptime
• scalability
• performance
• reliability

These are health metrics, and they are critical.
Tech debt is outcome-driven work.

Elad Simon | 30:22–30:48
Exactly. Health metrics are outcomes. They ensure your product can support future growth. They reduce risk. They improve customer trust.

Health isn’t “nice to have.”
It’s strategic.

Q&A — What If Leadership Isn’t Bought In?

Kate Fuchs | 30:48–31:02
A big one:
“What do I do if leadership isn’t aligned on outcomes?”

Elad Simon | 31:02–31:39
Sometimes leadership isn’t aligned because their only exposure to your work is a 20-minute readout every few weeks. Meanwhile, you’ve been living it for months.

So create more touchpoints.
Show work-in-progress.
Show user feedback.
Show the outcome logic early and often.

Bring them along during the process, not only at the end.

Joe Ghali | 31:39–32:06
And make strategy tangible. Leaders often love the idea of outcomes but don’t understand the mechanics.

Show them the Outcome Tree.
Walk them through problems, metrics, hypotheses.
Help them see how product management creates business impact.

Over time, that builds alignment.

Q&A — Objective vs. Metric

Kate Fuchs | 32:06–32:19
Here’s a great one for Joe:
“Should objectives themselves be metrics?”

Joe Ghali | 32:19–32:51
My opinion? No.

Objectives should be aspirational — they describe the desired end state.
The key results / success metrics measure progress toward that end state.

Objectives inspire.
Metrics measure.

Keep those roles separate.

Q&A — When Objectives Are Too Aspirational

Kate Fuchs | 32:51–33:00
And on the flip side:
“What if an objective is too aspirational?”

Joe Ghali | 33:00–33:38
Yes — this happens all the time.
If an objective is so aspirational that it’s demotivating (“build an encampment on Jupiter”), then it’s not useful.

Objectives should stretch you — not break you.
Use company vision, mission, culture, and capabilities to calibrate how far is too far.

Ambitious is good.
Impossible is not.

Final Questions & Chat Wrap-Up

Kate Fuchs | 33:38–34:03
We’re wrapping up here. Any final questions, drop them in the chat. We’ll be sending the recording out to everyone.

Joe Ghali | 34:03–34:22
Thank you all — these conversations were fantastic. It’s great seeing folks from all over the world joining today.

Elad Simon | 34:22–34:43
Yes — thank you. Wonderful questions, great engagement. This is clearly a topic many of us are wrestling with.

Special Offers & Upcoming Trainings

Kate Fuchs | 34:43–35:12
A reminder:

• Download the free Leader Pack
• Use the 20% off Craft.io offer
• Check out our upcoming trainings, including Digital Product Management and Optimal Product Management
• And Joe’s in-person session in Wisconsin — highly recommended

Closing Remarks

Joe Ghali | 35:12–35:26
Thank you, everyone. This was such a great group. I hope to see some of you in class.

Kate Fuchs | 35:26–35:40
Have a wonderful rest of your day and week. Thanks again for joining us.

Elad Simon | 35:40–35:46
Thank you! Bye, everyone.