Subscribe
Share
Share
Embed
You shipped the feature, closed the ticket, merged the PR — but do you have any idea if it actually mattered? If you want to know how to be a better product engineer, this episode is for you.
In this episode, I explain why business outcomes are lagging indicators you can't directly control, while product outcomes are leading indicators tied to user behaviour that your team can actually influence. I walk through the Cynefin Framework, how to test if a product outcome is any good, what a feature factory looks like, and practical things you can start doing right now to speak the language of outcomes.
TIMESTAMPS
00:00 Why Engineers Never See the Feedback Loop
03:00 Business Outcomes vs Product Outcomes — The Definitions
07:00 Why Product Development Lives in the Complex Domain (Cynefin Framework)
09:00 How Business Outcomes Get Translated into Product Outcomes
12:00 The Four Tests of a Good Product Outcome
15:00 From Features to Experiments — Redefining “Done”
18:00 The Feature Factory and Vanity Metrics
21:00 What You Can Do as an Engineer Right Now
25:00 The One Question That Separates Product Engineers from Software Engineers
RESOURCES MENTIONED
* Cynefin Framework by Dave Snowden
CONNECT WITH PRODUCT ENGINEERS
Host: Peppe SillettiLinkedIn: https://www.linkedin.com/in/peppesilletti/Website: https://peppesilletti.io
Product Engineers Community:Website: https://productengineers.comLinkedIn: https://www.linkedin.com/company/product-engineers
SUPPORT THE SHOW
If you’re an engineer who’s tired of just closing tickets without knowing if any of it mattered — share this episode with your team. Drop a comment with your biggest takeaway.
This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit
Product Engineers is the podcast about the convergence of product and engineering in the AI era: what's breaking, what's working, and the craft of doing both well.
Hey, what's going on, guys? So today, we're going to talk about something that most engineers never really think about because it's something that is usually responsibility of the product manager, and that's outcomes.
I mean business outcomes, product outcomes, what they are, what's the difference between them, how they work together, and most importantly, how you as an engineer can use them to have a way bigger impact in the work you do.
So yeah, let's get into it. [upbeat music] So here's the thing. For most of us as engineers, we measure success by shipping code. The feature is done.
The ticket is closed. The PR is merged. So you go to the next JR ticket. Maybe you will hear from QA a few days later because the customers are complaining, and there's a bug you need to fix.
But, you know, th- that's kind of where it ends for the most of us. We, uh, rarely find out what actually happened with the thing we built. Did it help anyone? Did people actually use it?
Did it move the needle for the business? We just don't know. The thing is, it's really when you ship the code that the feedback loop starts, and the problem is, is, is that we never see it closing.
And I think it happens for two reasons. So first of all, I think we inherited practices from more traditional industries like factories and construction, with engineers sitting at the end of the assembly line.
Someone else is designing. Uh, someone else, uh, is, is planning, and we just build what they tell us to build. And unfortunately, a lot of companies still operate like this.
[laughs] Second, I think, um, it's also a bit on us because we kind of got a bit too obsessed with technology.
We obsessed over how to name a variable, a, a lot of architectural debates, and all these refactoring requests. You know, all of that.
And look, I, I think they are all valid things, but the problem is we never really learn to connect them with what the business actually cares about.
We go to our managers, and then we ask them time to, uh, you know, fix technical debt, and we can't really explain why it matters in business terms.
And then we are kind of surprised when leadership says, "No, you can't do that," or, "There is no time." So that's why I want to break down two concepts today. Uh, what are business outcomes and product outcomes?
I believe once you understand the difference between these two things, you'll start speaking the same language as product people and business people. I think eventually you can
also start bringing your own ideas to the table, which is really where things get interesting. So, um, le- let's start with the definitions because I think this is where a lot of people get confused.
Um, I got confused about this for a long time actually, so let me try to explain it in the simplest ways I can. A business outcome is a lagging indicator, something like, uh, revenue, churn, or market, market share.
By the time you see churn going up on a dashboard, the damage is already done. That's why it's called lagging.
The customers had a bad experience weeks ago, and you're looking at the rear view mirror, and it's very difficult to intervene there to change the outcome.
While a product outcome is a leading indicator because it measures what users actually do inside the product, which is their behavior. And because it's about behavior, your team can directly influence it.
You can change the experience, run experiments, and see what happens. The relation between the two outcomes is that product outcomes drive business outcomes.
If you pick the right product outcome, improving it should improve the business outcome, too. That's actually the, the bet you're making. It's...
There is no a guaranteed one-to-one causation, uh, be- because, you know, product development, uh, falls into the complex domain. But you can make, uh, the best bet you can, right?
So let's say, for example, uh, let's take reduced churn as a business outcome.
You can, uh, see it on a, on a dashboard, but you can't really do much about it directly because there are a million reasons why people churn.
Uh, but instead, if we think about if we take increase the number of users who successfully complete onboarding, now yeah, that's a product outcome because it's a specific behavior that your team can design for and/or you can experiment with, and you can also measure.
So for example, if more people can get through, uh, I don't, the onboarding phase smoothly, maybe fewer of them will churn.
Now, just to help you understand a bit better, uh, let me give you, like, an engineering analogy because, you know, I think this will really click for you. Think about, uh, system reliability.
The business outcome could be the same as the system should always be up and running. But, you know, you can't really full control that as an engineering team, right? Because a traffic spike can hit.
Uh, there could be another team introducing a bug or some unknown unknowns that can bite you at 3:00 AM. But, you know, you know, there are too many external factors that you have no control over.
So what can you do instead? You focus on something that you can actually control.
So for example, you track the percentage of deployments that go through a full CI/CD pipeline with hopefully-Automated tests coverage, and that's kind of your, uh, leading indicator because you ship small incremental changes, each covered with tests, automated tests, and that will probably reduce the risk of shipping something broken.
Now, uh, your tests might be wrong or bad implemented. You could have flaky tests, which are not good, right? But, you know, it still removes a whole category of problems. And so the logic is, is similar.
You focus on what's measurable behavior that you can change, um, because that's exactly what can, what can drive the act- outcome you care about. Now, you might be asking, um, "Why are we thinking in terms of bets?
Why can't we just plan our way to better business outcomes?" Well, [laughs] I think if that'd be the case, everyone would be rich on Earth, right? Um, so th- th- that's, that's definitely not how it works.
There's actually a, a very interesting framework that explain this very well. It's called Cynefin framework, and it's from Dave Snowden. Cynefin offers, uh, five decisions making contexts or domains.
This help decision-makers identifying how they perceive situations and to make sense of their own and others people behaviors.
So the, the one domain that w- it's interesting for us is the complex domain, which is exactly the domain where product development lives.
What makes complex domains unique i- is that cause and effect only makes sense when you look back at them, um, like in hindsight. You can't really predict what's going to happen up front.
So instead of just planning, executing, and then measuring, you need to do, uh, what's called probing, sensing, and respond.
So you ship something small, you measure what happens, and then you adjust, and that's exactly what product outcomes enable. They will give you something concrete to sense against, so you're not just flying blind. And
here's the thing, engineers kind of have this instinct already, right? So when you're debugging something, uh, after a production incident, you don't just go out there and write a 50-page plan before you start.
You form a hypothesis in your head, you check the logs, you try something, and you see what happens. That's exactly the probe, sense, respond loop, and product development works exactly in the same way. All right, so
now that you understand the difference between product outcomes and business outcomes, let me talk about how business outcomes actually get translated into product outcomes.
I think this is really important to understand. So let's say you go to your product manager tomorrow and you ask, "Hey, um, what's our product outcome?" And they say, "Well, we need to increase revenue." Well, um,
it, it's a bit of a red flag already because that's really a business outcome, not a product outcome. What it means probably is that leadership hasn't done the work of translating the business to product outcomes.
And by the way, this happens all the time, so i- it's not like a, a unique situation. So don't be, don't be surprised if your PM replies you, to you like that. So how does the translation actually works?
Um, basically, leaders need to get spec- very specific about what people will do differently to meet the business outcome. Increased revenue i- is very vague, right? Doesn't mean anything.
But if we can say like some- something like, "We think existing customers will start buying more per transaction," now we're talking about a real behavior that someone on the product side can actually work with.
So let me give you a even more concrete example. Um, let's keep, uh, increased revenue as a business outcome. The leader's behavior- behavioral bet, because it's always a bet, is we want to increase order volume.
Um, we want to, we want existing customers to buy more per transaction. The product team picks a metric, which could be, "So let's increase the percentage of customers who add a second item to the order."
And then the team goes out there and explores different solutions to ma- to move that metric. Maybe it could be like a recommendation system, maybe it's bundles, or maybe it's something completely different.
But, you know, the metrics is, is the same, is, is, it's very specific. And oh, one, one, one more thing. Um, one business outcome doesn't map to just one product outcome.
There could be multiple ways to change behavior, and that's actually a good thing, right? It gives you a bigger opportunity space to explore.
If you want like the engineering version of this, it's the same thing you do when your team gets the goal, like improve system performance. That's way too broad to act on, so what, what do you do actually?
The most sensible thing to do is to break, to break the problem down, uh, because maybe, um, one person could look like, uh, at, uh, queries. Another person can look at front-end bundle size.
Someone else can tackle API response latency. Each of these are very specific and measurable things that you can actually work on.And e-each one contributes to the, to the bigger goal in its own way.
That's exactly how business goals get broken into product outcomes. So you start from something broad, and you find the specific levers you can pull. All right, so now,
um, you understand what product and business outcomes are, and how they, uh, connect to each other. But how do you actually know if a product outcome is any good?
Because not all metrics are created equal, and this is where a lot of teams mess up also. So a good product outcome basically passes four tests.
The first one is that it's controllable, so your team can actually influence it through the product. If it depends mostly on external factors, you're just hoping that things work, right?
So the second one is the outcome, it's measurable, so you can track it with real da-data, not just gut feeling.
The third one is that it's a leading indicator, so it tells you something is changing before business outcomes moves.
And last, the fourth one, it's that the outcome is connected to user behavior, so it reflects something people actually do in the product or something that they feel, not just some internal process metric.
So let me give you, like, a quick test. Um, think about reduced number of support tickets. Is that a good outcome or a bad product outcome? Well, let's think it through. Um, is it measurable? For sure.
Is it controllable by the product team? Kind of, partially. Is it leading? Maybe. Is it connected to a specific user behavior? No, not really. Because it's, it's more of a symptom than a behavior, right?
A better version would be something like, mm, the percentage of users who complete the setup flow without contacting support.
It, it's kind of the same thing, but you're tracking a specific behavior that a team can actually design for. Um, as an engineer, you already applied these four tests without realizing it in your own work.
Think about how you pick alerts for your monitoring system. A good alert is controllable. Your team can actually fix what triggered it. It's measurable because there's a clear threshold.
It's leading, so it fires before the system goes down, not after. And it's connected to real system behavior, which could be CPU load, memory usage, or error rates.
A bad alert is one that fires constantly, nobody can act on it, and everyone just ignore, ignores it, right? So that's exactly what a bad product outcome looks like, too. Noise that doesn't lead to action.
All right, so once you have your product outcome, the game really changes. You're no longer just building features, you are basically running experiments all the time.
And this is where it gets really exciting for engineers because it's the closest thing to the scientific method that we do in software. The idea is simple.
So you define the outcome before you write a single line of code. What behavior do you expect to change? How will you measure it? What does success look like?
And if you can't really answer any of those questions, honestly, I think you're not ready to build yet. You're just guessing.
So after answering these questions, you then ship the smallest thing that you can build to test those assumptions, the smallest version that lets you learn whether you're on the r-right track.
Maybe it could be just a single screen, maybe it's a simplified flow, maybe it's even a fake door test where you just measure if people click on something that doesn't even exist yet.
The point of all of this is really to learn fast, not, not to build something. This is where the definition of done gets really redefined because in most teams, done means merged, maybe even deployed.
But in an outcome-driven team, done means validated. Did the metric move? Did the behavior change? So if the answer h- is yes, then yeah, okay, double down on it.
But if it's no, you may want to pivot or just try something else. The PR being merged, it's really just where all of this process starts. And here's the engineering analogy.
This is basically continuous delivery applied to product thinking, so small batches, fast feedback, incremental progress. And as engineers, we already know how to do this with code, right?
We deploy the small changes, we monitor, we roll back to a previous version if something breaks. The outcome loop is exactly the same thing except that instead of monitoring error rates, you're monitoring user behavior.
And just like continuous delivery falls apart without proper monitoring, the outcome loop falls apart without proper, proper instrumentation. If you can't measure it, you can't learn from it. So
now I want to talk about what happens when teams don't think about outcomes at all. And you've probably heard these terms before, like feature factory, code monkey, pixel monkey, Jira monkey, all of that.
And that's exactly what you get when teams focus on outputs instead of outcomes. An output is something you can check off a list, right?
Whi-while an outcome, it's something you can measure over time.Shipping a feature, uh, can feel like progress, but if nobody uses it or it doesn't change behavior, um, it doesn't really matter. It, it has no value.
An output has no value inherently. It's only as valuable as how much it solves a customer pain point or, or how much it satisfies a need or, uh, fulfills a desire of the customer.
So if you're wondering how to recognize the feature factory, just look for these patterns. So you have a very long backlog with a l- a very long list of things to do, so which looks like more of a to-do list.
Then the team every week picks up a task for the sprint, then checks the box when something is shipped, and then moves to the next one, and they just keep going and keep going until eventually someone realizes that all this shipping without measuring impact is a terrible idea.
But, you know, by then, a lot of time and money has been wasted. Also watch out for what we call vanity metrics, because they're basically output metrics disguised as outcomes.
For example, number of features shipped or lines of code written or story points completed. They look like you're measuring something meaningful, but they're just outputs wearing a metric costume.
They will tell you if your team was busy, but not that anything got better for the customer.
A team can absolutely crush their story points every single sprint and still ship a product that nobody wants, and I've seen it happen multiple times. Now, outputs per se are not a bad thing.
It's just the focus on outputs that is bad, s- because you still need to build something of course to reach your outcomes.
But the output without outcomes in mind, that's a really bad place to be in, and you don't want to be there. So what can you do as an engineer with all this knowledge now?
I think this is where it gets a bit personal for me. At a certain point in my career, I started thinking, "Okay, I'm building all these nice interfaces.
I've got all these well-designed backend systems, and I want to see people actually using it. I want to know if it was useful for them." Um, and I really wanted to bring ideas to the table.
But in my experience, there wasn't always a space for that because, you know, um, engineers have been for a long time sitting at the end of the assembly line,
and I really got frustrated about it, and it's that frustration that, that really led me to explore all this product engineer's world.
So I think the best thing we can do as engineers is start asking better questions, not going against the product team or the business team. Just, just stop saying yes to everything like a donkey.
So here's what you can actually do, and these are things I've tried and done myself. First of all, ask for more context.
Next time your PM hands you a ticket, just ask, "Hey, maybe could you give us a bit more context on why we're building this? I really think it can help me come up with a better solution."
Don't just ask, uh, "Why do we have to do this?" You know, [laughs] it's very direct, and I think it sounds very confrontational. Uh, you need to frame it with cur-curiosity, and in my experience, 90% of the time this is
really well-received because, you know, I've had PMs, uh, be generally, uh, generally surprised and grateful that someone on the engineering side even asks something like this.
And, and but you also will find the ego-driven PMs who think they are the CEO of the product, and they have all this power, and in that case, honestly, um, find a better team.
[laughs] And you know, I know it's easier said than done, but you know, life's too short to fight ego battles. Another thing you can try is proposing solutions that can help the team, uh, achieve the product outcome.
So once you know what product, product outcome your team is chasing, you are kind of a, in a unique position because you can see the code base. You know what's technically cheap to build.
You know where the bottleka- bottlenecks are.
And maybe the designer is mocking up a very complex feature that'll take three sprints to build, but you know that there is a simple version that you could ship in a week and test whether it, it actually moves the metric.
That's way more powerful than just saying, "Hey, I have an idea. What do you think?" Another thing you can try is connect your technical work to outcomes, and I think this is one, this one is huge.
Uh, so don't just go to your manager and say, "You know, we need to refactor the auth model, auth model." Instead say, "The auth model has three seconds to log in, and we're losing 50% of users at that step.
Fixing it should improve our activation rate." It's the same work, but it's a completely different conversation, right? And remember, user experience isn't just visual stuff.
Um, faster queries, better performance, smoother interactions, these are all technical contribution to product outcomes that only engineers can make. Um, you can also try to read your analytics.
Most engineers have access to product analytics tools, but they literally never look at them.
You can spend like 30 minutes looking at user flows, and I guarantee you you'll spot things nobody else sees because you know what the code is actually doing behind the scenes. You know where the bottlenecks are.
You know which API calls are slow. You know which features are held together with duct tape. And that context combined with analytics data, I think that's a superpower.
All right, so the shift from code monkey to product engineer comes down to one simple question: Did this matter? Speaking the lang-language of the outcome is what gives engineers influence over product direction.
You stop being an order taker, and you become a decision maker. You can push back on bad ideas with data, not just opinions.
You can propose what to build next because you understand the impact model, and honestly, that's what separates a product engineer from a software engineer. So here's my challenge for you.
Think about the last feature you shipped. Can you name the product outcome it was supposed to move? If you can't, go find out. That's your first step. If this episode was useful, please share it with your team.
Tell them to watch it before your next planning session, and subscribe to the channel if you haven't. And if you are on Spotify or Apple Podcast, uh, please leave a good review and follow the show.
Thank you very much for listening, and till next time.