Caught in the middle. That's how internal Product Owners often describe their work to us. Caught between stakeholders with conflicting goals, like "do it fast, but do it safely." "Experiment to learn, but follow the plan."
Caught trying to keep everyone happy, the business rep and the technical lead, your boss and her peers.
Caught between shifting priorities. "Finish everything on the current list, but add this new thing too."
Caught between stakeholders and the team. "Make commitments with this limited bit of info. Oh, and be sure to deliver value now and in the future."
Caught without enough authority to fix it. "You're empowered to make a decision, but don't change anything important without checking with me first." And caught In a split version of the role. "The product manager will talk to stakeholders. You focus on interacting with the team."
Internal Product Owners looking for help with these challenges quickly discover that most of the content out there for POs is oriented towards market facing Product Owners. The PO in most Scrum literature and most scrum PO training is a visionary guiding the team to create a product for external customers to buy and use. And that's not just a scrum problem. You can look at Lean Startup, Product Operating Model, all over the place. It's all oriented towards selling a product to external customers. An internal PO can look at that and say, well, I don't set vision or strategy. Guess my job is just managing Jira tickets a role that isn't particularly high leverage or particularly motivating.
But it doesn't have to be that way. The internal PO role can be valuable and really interesting. As we work with a range of Product Owners in different contexts, both internal and external facing, we've noticed some practices, tools and skills are easily applicable to both internal and external Product Owners. Some are framed for external Product Owners, but can be adapted to be really useful for internal Product Owners, and some are even more important for internal Product Owners than for external ones.
So in this episode, we'll look at a handful of examples in each category and dig into a few to show how internal POs can develop these important capabilities. We'll also explain how we're reshaping our advanced PO training specifically to meet the needs of internal Product Owners.
But first, a quick reminder that this episode is brought to you by the Humanizing Work Company, where we help organizations improve their leadership, product management, and collaboration.
Visit humanizing work.com to learn more about our workshops, coaching and online courses, or to bring us in to support your team.
And if you get value from this show and you wanna support it, the best thing you can do if you're watching on YouTube is subscribe to the channel. Like the episode, you can click the bell icon to get notified of new episodes and drop us a comment with your thoughts.
And if you're listening to the podcast, a five star review makes a huge difference in whether other people who'd benefit from the show find it or not.
Okay, let's break this idea down into three categories of practices internal Product Owners need as compared to external ones. And category one is what we might call foundational practices. Those that are essential, whether your customer's internal or out in the market. They don't change much from context to context, and every PO needs these. The second category are what we would call amplified practices. Things that matter to all Product Owners, but they're even more critical for internal contexts where roles can be blurry. There might be a lot of stakeholders and you need to pay close attention to power dynamics. And the third category, we'll call adapted practices. These are practices often associated with market facing products, and at first glance, they may seem less relevant internally. But with the right application, they give internal Product Owners a huge potential advantage.
Whether you're a product owner for an internal or external product, some practices are just as important and just as applicable. For example, structuring your backlog for continuous sustainable refinement, like with our PO board model. Um, sharing clear roadmaps that explain why certain things will be delivered when, and modeling value.
Let's dig into that last one. Value modeling is what we call being able to explain and align around the business value of an initiative or a feature. This is the way out of doing work just because someone with power requested a thing. And since internal POs usually have way more requests for things than they have capacity to do them, nobody ever tells me, "I've got this team and I don't know what to do with them if only there is something valuable to do," it's really helpful to be able to have conversations around the value of the work.
Now, a common mistake in value modeling is going to numbers too quickly. The desire to make prioritization a spreadsheet problem, just sort the spreadsheet and no more hard conversations about priority leads to people trying to quantify value right out of the gate.
SAFe's modified, weighted shortest job first model is a common approach that leads this way.
Yep. Instead, we recommend getting aligned conceptually on value before trying to put numbers on it. Joshua Arnold's four part model for economic benefit is a great starting point for thinking about value in this model.
Everything we do should lead to one or more of four kinds of economic benefit, increase revenue, protect revenue, reduce costs, or avoid costs.
And we believe it's not enough to just say what the intended economic benefit is. For any feature on the backlog, a product owner should be able to lay out what we call a theory of impact, which is a chain of cause and effect from a current undesirable state through building the feature step by step until that economic benefit happens.
In other words, don't just say, this feature will reduce costs, describe the current costs, and then walk through what happens in order step by step from building the feature to actually seeing cost go down. The theory of impact has nothing to do with how you'll build the thing, but everything to do with how users and customers will benefit.
It starts by assuming, okay, we've built the thing. Now what happens?
All right, let's look at an example. If we were doing value modeling for implementing a new CRM system, the theory of impact starts with something like, "well, right now sales and marketing teams spend a lot of time doing manual steps to keep track of customers and campaigns, and they can lose track of deals and not close as many as they'd like."
Then we describe implementing the solution and seeing a positive chain of cause and effect leading to the economic benefit. Something like, "okay, we implement the new CRM system and then those teams use the fancy automation to keep track of important leads, campaigns and deals. Then they lose fewer opportunities along the way. Then that leads us to increased revenue."
For something like this, for real, there's probably more steps in the actual theory of impact and probably more than one economic benefit. You, you might increase revenue and also reduce costs, for example. But even this level of precision, what we just rattled off here, is better than, "well we, we need to build it because someone with authority said to."
Right. And as you get more precise on the theory of impact, then you can bring more nuance into your value model. You can see spots where you can test and measure assumptions, and you can reason about how value changes with time, such as with seasonal benefits or market windows or regulatory compliance features that won't show a return until the new rule goes into effect in the future.
A refined value model also makes it clear to everyone involved what's actually important, and this helps teams make trade-offs. Should we make it easier to use or add more fancy automations?
Value modeling admittedly, is often harder for internal POs because there's some distance away from the people actually spending money.
But it's still critical to understand how your team contributes value to your business.
Alright, let's look at that second category, what we called amplified practices. These are things that are more important for internal Product Owners than for market facing Product Owners. For example, stakeholder management and conflict resolution.
External POs certainly have stakeholders they need to work with, but I think the closer you are to a paying customer, the more your stakeholder influence gets put in perspective.
Yeah, and for internal POs, there's often a large constellation of stakeholders. And it's often unclear who the real customer is and what success looks like. Without active management, the internal product owner can find themselves constantly reacting to demands from different stakeholders.
A good starting point is to simply brainstorm who your users, customers, and stakeholders are. There are more than you're thinking of right now. You don't wanna miss an important one, and each has something different they need from you, your team, and what you build, and probably vice versa.
There may be hidden great ideas in the conversations you'll have with them,
and landmines you might wanna avoid.
It's true. Uh, most of us probably have a few blind spots in this area. So we've come up with nine questions that uncover a wide array of stakeholders for our clients. As I share the questions, think about who comes to mind for you.
Um, if you're in a place you could do it, maybe even write some people down. As you think through these questions.
All right, first, the probably the easiest one. Who directly uses what we build? Who are your users?
Second, who selects and pays for what we build? Maybe it's the users, maybe it's somebody else. And by the way, for internal Product Owners, pays for may be, uh, paid with attention. So who mandates that somebody give their attention to this thing might not be the user themselves.
Number three. Who gets users to use what we build. This could be marketing and sales who helps users use what we build. For example, support people who benefits from someone else using what we build. This could be the user's customers. So if you're building something for a call center agent, who are they helping next?
Who contributes resources for building what we build? Maybe it provides things that you use or a vendor provides things that you use. They're stakeholders too.
Who works to avoid harm coming from the thing that we build. This could be compliance or legal.
Who sets constraints on our solution? Maybe enterprise architects or finance.
And finally, who integrates with the thing that we build? What other teams might there be that need to integrate with this thing?
And since we have nine questions to answer and we like round numbers, we'll give you a 10th source to uncover additional stakeholders, and that is, as you're talking to all of those people that you thought about in the first nine questions, you can also ask them, Hey, as I work on this, who else should I be talking to about it?
Then once you have your list, make sure you have proactive ways to keep up with each person or group on the right frequency, which is to say, as often as things are likely to change that you would need to talk to that person about.
All right. Finally, let's turn our attention to the third category, adapted practices.
These are things from the quote product space that internal POs often see as irrelevant, but they can become major advantages if you adapt them a little bit. Things like customer interviews, product assumption testing, product instrumentation.
Yeah. Let's look at product assumption testing. It's all the stuff that comes from the Lean Startup world and the many books that have been written since then.
Since Lean Startup is framed around finding product market fit and getting customers to pay for your product and then venture capitalists to fund your growth, it's easy to disregard this stuff for internal Product Ownership. But if you zoom out from the startup context, it's really about making your assumptions visible and then looking for fast and cheap ways to test the riskiest assumptions that's totally still relevant for internal product ownership.
Internal initiatives start with unvalidated assumptions, just like external facing products do. Testing those is a great way to avoid wasting time and money going in the wrong direction.
David Bland's book Testing Business Ideas is oriented towards the startup context, but at least half the experiment types in there apply to internal products too. And the overall approach of framing risky assumptions as hypotheses and designing validation tests for them is solid. Internal POs actually have some advantages for product assumption testing because of access to users. The trick though, 'cause it's a double-edged sword, is actually designing good experiments rather than just asking people what you should build.
As we've worked with more and more internal Product Owners across our clients, we see an unmet need for skill development beyond the basics, but oriented towards that internal product context. So we're launching a new version of our advanced product owner program, specifically designed for internal Product Owners.
We'll be going deeper into everything we touched on in this episode: Value modeling, roadmap, stakeholder management, conflict resolution, product assumption testing, customer and stakeholder interviews, product instrumentation, and lots more. The first public cohort will start in fall of 2025. And we're already talking with clients about customized private cohorts.
If this is something you're interested in, we'd love to hear from you. What skills do internal POs need most to succeed in your context? Comment on the episode on YouTube or LinkedIn, or shoot us an email at
[email protected]. Thanks for joining us in this week's Humanizing Work Show.
