Product Ownership

In today’s ever more Agile and IT-driven businesses, the product owner’s role is expanding outside the traditional product management domain. My last two employers within the last eight years have required hybrid technical and product-oriented roles. Even if we aren’t in a hybrid position, a shared understanding and skillset can help both disciplines collaborate more effectively.

Borrowing from the hardware world, I call this hybridization approach Product Engineering. Let’s dig into what that means exactly and how to approach product ownership from a product engineering perspective.

Engineers Produce Documents

Robert Martin distilled engineering down to this simple statement. The engineering discipline is a design documentation discipline. In software, an engineer creates source code documents. Those documents are eventually translated by software into instructions that are understood by the processor. The source code documents aren’t what is running. Our processors don’t speak C# or Java. Just like a civil engineer doesn’t build a bridge. Instead, they create documents explaining how builders will build the bridge.

For a civil engineer to build a successful bridge, they need to understand physics, construction techniques, and the tools used in construction. Otherwise, their design might not be feasible. Even if it is, it may not be profitable or marketable. The customer will likely even ask the engineer to produce several options with different cost structures over different time horizons laid out against functional strengths and weaknesses. So the engineer needs to understand how their design impacts cost and value too!

In software development, it is common to hear engineers say things like, “Just give me the specs, and I’ll build it.” This relationship isn’t unreasonable because the cost of changing software is incredibly low compared to something like a bridge. However, the technology landscape is now hyper-competitive. Inventing something new is pretty rare now relative to the amount of software produced. Many teams are focused on making something that already exists better. To draw out a competitive advantage requires optimization.

A software engineer knows the tools and techniques for building software. Given some knowledge about markets, cost structures, and value propositions, they can further shift requirements defects toward the left. A product manager who understands the tools and techniques for building software will produce more effective specs and help drive sustainable productivity.

A product engineer produces documents describing the product informed by knowing the fundamental sciences, tools, and techniques used to create commercial software.

Finding Opportunity

Whether we are looking to solve problems internal to our business, enterprise customers, or consumers, we need to find opportunities to create value. To find opportunities, we first need to understand the broader context we work in. We must understand the importance and purpose of our company’s vision, mission, goals, and strategy, so our products are relevant and impactful.

Here are some questions that can help us understand the context and find clues about opportunities:

• What is the most challenging part of our strategy to execute?
• Which goal is the most important to our success and which is most at risk, and why?
• Which parts of our portfolio least represent our vision and mission, and why?

Next, we can look at the market. What problems aren’t being solved by current products? And most importantly, why not? If it’s a technical problem, there could be an opportunity to put together a team capable of solving the problem. But solving the technical challenge is only one part of bringing a product to market. We also need to know if there are pricing, distribution, or profitability problems to solve. Until we see the marketability challenges, we won’t understand why a product isn’t on the market. We definitely won’t know how to bring a viable solution to market.

If we can find an underserved market, then we can start to understand the customer. Like with our business, we need to know our customer’s goals, how they are trying to solve them, what’s working, what isn’t, and why.

It’s important to understand that our customers are exactly like the rest of us: unique, diverse, and have shared experiences, needs, and desires. We should always view our customer as an expert in their world. We can never lose sight of that. But not all customers have solutions to their problems. And customers vary in their ability to see and understand the issues they face.

Some might say that customers don’t know what they want until they see it, and others that the customer should be the product owner. These are both true, and all points in between, depending on the customer and our relationship with them.

Regardless of the type of customer we have, we need insight into their goals, how they are working toward them, and what’s keeping them up at night. We can use a combination of formal and informal approaches tuned to the kind of relationship we have with our customers.

• Lunches or Dinners
• Sprint Reviews
• User Interviews
• Work Studies
• Feature Requests & Bug Reports
• Survey Results
• User-behavior Analysis
• Kaizen Sessions
• Event Storming
• Personas

If we have competitors, we can also find opportunities by analyzing their position in the market, distribution approach, and product features. A SWOT analysis of competitors is a great starting point for finding opportunities to create competitive advantages.

What’s taking shape here is the top of an opportunity funnel. These opportunities might be products, features within a product, distribution models, development models, or technology solutions. In a world full of opportunities and risks, we need to narrow this funnel.

Investable Opportunities

Not everything that creates value or is profitable is necessarily investable. And not every product must be directly profitable. The broader context of our business strategy, risk aversion, time horizons, and portfolio strategy are factors that should influence our willingness to invest. The software engineering practice of Domain-Driven Design (DDD) provides us a framework that we can also use to help us prioritize investment. I’ve modified it slightly for emphasis.

Alignment	Investment Strategy
Strategic Business Domain	Best In-House Team
Supporting Business Domain	Jr. In-House or Outside Team
Outside of Business Domain	Outside Team, Vendor, Commodity, or None

This model can work at many scales, including down to modules and microservices. While a product might be in the strategic domain, not all of the product’s features will be. Feature level optimization is one area where the product engineering approach shines. And a background in software engineering will allow you to see misalignments at an implementation level.

For example, let’s say we are building a fabulous product management suite. We know that UX is strategically essential in the onboarding, administration, and portfolio visualization modules from our research and analysis. But many trivial CRUD operations need to be created. We don’t need our best and most specialized UX designers and software engineers on these problems. We know that solving portfolio visualization is difficult, complicated, and time-consuming. It also is our key differentiator. We need our best people to solve this problem, but we can’t just ignore the other stuff, or there’ll be nothing to visualize!

A product engineering approach can help divide the software architecture into appropriate business problem domains. Along with a highly modular UI, we can then split the product based on alignment and invest at proper levels while optimizing productivity.

By aligning the product and the actual code with our business strategies, we expand our opportunities to create significant competitive advantages.

ROI & Profitability

We have narrowed our opportunities down to those that best align with our higher-level strategies. By doing so, we have put aside some work that could have profitable returns in hopes of maximizing our competitive advantage. It takes discipline and commitment to the strategy to pass by opportunities. Now we need to prioritize what remains in our opportunity funnel.

First, we need to understand how the higher-level strategy influences our time horizons. When we talk about ROI and profitability, we have to understand the timeframe and scope. For example, I was under direction from my leadership for a couple of years to only engineer solutions that would have ROI within three months of starting development. A short time horizon changes many of the ways we have to approach product management and engineering. In this case, I pursued a highly iterative approach that pushed out quick and dirty MVPs. Then, the development would stop to wait for a return. I was able to get a product development rotation in place that kept the team productive. While far from ideal, the tactics fit the context of the organization’s strategy, risk tolerance, and time horizons.

In other contexts, a given product might not have to be directly profitable at any point in time. A product might exist solely to funnel customers into profitable products or services, which is why we can’t talk about ROI and profitability outside the context of our business goals and strategies.

Whether we are working with short or long time horizons, direct or indirect profitability, or high growth or optimization, we will want to track some metrics. Exactly how we use them will depend on our product and portfolio goals.

• Cost to Acquire Customer (CAC)
• Lifetime Value of Customer (LTV)
• Total Cost of Development (TCD)
  • Should include support and infrastructure costs in addition to the development team.
• Revenue
  • Suppose the product isn’t revenue-generating. In that case, we’ll want to measure cost savings or downstream value creation in some way.

We’ll also want to start to predict future outcomes based on known growth data. Projections will help us understand what we need to invest in to support scaling and optimize returns. One of the stickiest of wickets is to be a victim of our success. Even if imperfect, sound predictions of growth can keep us ahead of the game without over-committing to specific features, architectures, and infrastructure.

Early Design & Planning

So far, we’ve narrowed down our opportunities based on what the market, our customers, and our broader strategy has to say. Now, we need to get a sense of how much it will cost and when we can deliver. Before we plan, we will want to define a compelling vision and a solid product strategy. We want these documents to serve as guideposts that can be adjusted as we learn more.

Suppose we already have our development team lined up. In that case, we will want the team involved in creating the vision, strategy, and roadmap. Having team input will make realistic roadmaps much more likely.

Product Vision

The vision should speak about the product’s purpose, be clear and concise, and inspire. It must also serve as a check against doing work that we should defer.

“The preferred choice of small to mid-sized technology businesses for managing the complete product development lifecycle.” would be an ineffective vision. It contains some actionable information, but it isn’t inspiring and says nothing about what the product is trying to accomplish.

Here’s a more compelling vision: “Connect development teams with their impact on business strategy and outcomes.”

The vision shouldn’t often change, maybe after several significant changes in product strategy.

I’m a fan of Roman Pichler’s product management tools, and his vision board comes in handy here as well. One of the reasons I love the vision board is how cleanly it moves into a strategy.

Product Strategy

Once we have a shared vision of the change we want to create, we can start working out our product strategy. Our strategy will be more fluid than the product vision. We’ll want to review it once a quarter and adjust as needed.

The strategy should include information about the market & customers, how our product will uniquely meet our customer’s needs, and our product’s business goals.

We will focus this strategy on how we will get the product to its next lifecycle stage. If it’s the early days, we want to determine viability and market fit. Our strategy should help us do that. Suppose we have a mature product in a competitive market. In that case, our product strategy should describe how we will create an advantage.

Goal-Oriented Product Roadmap

A goal-oriented product roadmap is a high-level document that takes our customer, market, and business goals from our product strategy and breaks them down into smaller, measurable chunks. The roadmap documents our quarterly goals, metrics, and what general features will achieve those goals.

I’ve seen quite a few roadmaps for Agile teams that look more like Gantt charts from the old days of waterfall project management. I shy away from this type of roadmap for these reasons:

• Focus on what and not why.
• Features over business results.
• Precise deadlines can disrupt sustainable and predictable productivity.
• Rigid planning lessens the value of learning from short development cycles.

While there are specific industries, markets, and products that demand feature delivery on particular dates, that isn’t true of most products. What’s more important than features and dates is the resulting impact on the business. Product managers who are myopically feature-driven run the risk of losing sight of their purpose, maximizing value.

Focusing on slightly ambitious goals that have a material impact can help motivate and align your development team and organization.

A goal-oriented roadmap will look something like this for that imaginary fabulous product management suite:

Timeframe	Q1	Q2	Q3	Q4
Lifecycle Stage or Milestone	Market Fit	Marketability	US Release v1	Euro Expansion Prep
Goal	3 SMB Beta Customers	6 SMB Customers	36 New Customers	3 Euro SM Beta Customers
Metrics	Meet 10 Potential Customers AVG 30 MAU	AVG 60 MAU	200 new trials. AVG 100 MAU	AVG 150 MAU Reduce onboarding time by 70%
Features	Okta Auth Product Vision Tool Product Strategy Tool Product Roadmap Tool SaaS	Free Trial Kanban Roadmap to Storyboard Storyboard to Stories	Scrum Sprint Planning Tools Smart Estimator	GDPR reporting GDPR data controls New signup form Google Auth

Each quarter, we will review our hits and misses and adapt our strategy and roadmap based on what we have learned. We might find our metrics didn’t predict hitting our goal or that our product goal didn’t impact the business. It is also important that we tune our goal setting. Goals that we hit easily won’t help us drive growth, but impossible goals will demoralize the team. I like to target goals with around a 70% likelihood of achievement. A bit of a stretch, but attainable.

It’s vital to gain consensus and commitment from the development team and stakeholders. Commitment, in this case, is a dedication to our shared plan, goals, and vision. We will then be taking the next quarter and breaking it down into the product backlog.

Product Backlog

Each feature in our quarterly roadmap might represent one or many user scenarios/epics, user stories, or tasks. At first, we will breakdown a roadmap feature into high-level user scenarios. We will add only enough detail to give a reasonable SWAG estimate. When the roadmap feature isn’t a complex scenario, we simply break it into stories. We will use these SWAGs as another gut-check for delivery within the timeframe.

We will want to retain the relationships between roadmap features, epics, and stories to track our progress and see if our work moves us closer to our goals. Project management tools usually aren’t well suited to address product management concerns. We might have to shoehorn in some custom fields or reimagine the structures within the app.

For example, Jira can track and forecast the burndown of “fix version” releases and epics. If it works well for the team, we can use “fix versions” to follow roadmap features, but then we lose out on milestone or lifecycle tracking. We might use epics instead, but we will end up in situations where a roadmap feature epic comprises many user scenario epics. Either way, we will have to track something with a custom field if we want reliable reporting and forecasting from Jira.

We are accountable for the quality and efficacy of the product backlog. However, that doesn’t mean it’s our fiefdom or walled garden. Sharing ownership with the entire development team, stakeholders, and even customers (where appropriate) can produce valuable insights and increase commitment. The more engaged the team is with the backlog, the more scope can creep. Avoiding distracting creep is one reason why we want to keep relationships with roadmap features and goals apparent.

Once we have a shared understanding of the quarter’s product backlog and SWAGs, we will begin breaking down the work into units that the development team can accurately estimate. Before we can start breaking down the backlog, we need to decide how iterative our development process will be. The old analogy about how to arrive at better than walking travel comes in handy. Do we first deliver rollerskates, then a scooter, then an e-bike? Or, do we start building components of an e-bike right away?

Answering this question depends on what we know and don’t know about our market, customers, and business strategy. If we know ahead of time that we can’t get early customers with a rollerskate solution, we aren’t buying any additional information. If we aren’t sure, then we should test it out and see if we can create value now rather than deferring it.

Continuous Planning & Design

We must work with our team and stakeholders to figure out what events and cadence will be most effective for continuous planning and design. We are accountable for having a product backlog and sprint goal ready to negotiate for each sprint planning. How we get there depends on a variety of factors. As a group, we will decide on using refinement events, refinement during sprint planning, or continuous refinement.

Sprint Goals

As product owners, we will come to sprint planning with a clear and testable goal in mind for the sprint. However, we must be open to negotiating the sprint goal with the development team. Again the goal should be a little stretchy but within the team’s capabilities. The better we understand the development team’s abilities, the more reliable the sprints will become.

When we draft a sprint goal, it should be something testable. It might be binary “deliver customer sign-up flow.” Or it could be a targeted incremental improvement, “reduce user interactions needed to sign up by 30%.” There shouldn’t be any doubt if the goal is achieved or not by the end of the sprint.

Sprint Planning

Our purpose in planning is to represent the customer as best we can. We’ll take our learnings from the last sprint review and customer feedback and then reflect them in the backlog. Our role in planning is to facilitate accurate estimation and sprint backlog item selection. We must confine ourselves to providing information to empower the team. The development team is accountable for delivering the agreed upon sprint goal, so selecting the sprint’s stories is their responsibility exercised with full ownership. We can help them succeed by providing:

• Clear testable user acceptance criteria
• Encouragement to debate the appropriateness of acceptance criteria
• Time for technical requirements to be discussed and documented
• Clarity on the business case for goals, stories, and acceptance criteria

It isn’t our role to question estimates. If we find that the team isn’t predictable or operating below optimal velocity, we’ll work with the Scrum Master (or equivalent) to drive improvements. While it isn’t our place to question estimates, we do want estimates to be meaningful. A close working relationship with our Scrum Master will go a long way.

Sprint Review

In the sprint review, we will directly represent our customers if we can’t have customers participate. We will verify whether the team met the sprint goal and acceptance criteria for user stories. We will provide input to the team and draft up new stories where needed. Some of this input should be new data coming from the released work. We want to put the impact of the team’s work front and center!

Lifecycle Management

Product lifecycles vary in complexity by industry and market. Generally, I’ve found the following high-level approach to lifecycle management adaptable and useful for driving business outcomes.

This cycle does not account for what happens after growth. We might move into a sustain stage or end-of-life. At any point through the cycle, we might find we need to pivot and go back one or more stages, move the product into a sustain stage, or drop it completely.

We can even apply this cycle to features within the product itself. Applying this cycle to features is easier with robust user behavior instrumentation, an iterative product development approach, and mature business intelligence.

Concept

This stage is about proving out technical feasibility. When we are confident in engineering needed, we don’t necessarily need to go through a distinct concept phase. We might bake micro-sized prototypes into sprints or move straight to determining viability.

Another cause for a concept phase is when we need to garner support or funding for developing a viability test. When this is the case, our concept will look more like an early iteration of our viability product.

Viability

I’ve been deliberately shying away from the term MVP. I’ve heard others describe MVPs as minimum sets of functionality or even a complete customer beta test release. For me, the emphasis of this early stage is on viability within the market. Those descriptions might be entirely accurate for a given product and market but I prefer to focus on general market viability.

The goal of this stage is to discover information. Is our analysis of our customer needs correct? Is our solution significantly different than the competitors? Does our product solve a customer need as effectively as we imagined? Are there customers?

Going back to our example of an imaginary product management suite, we believe “Aha!” customers are unsatisfied with their inability to create and link standard Scrum PO artifacts. Our theory is that a portfolio visualization that connects product vision, strategy, and roadmap would be a good first test of viability. We then demonstrate the features to a potential customer and find that they love the workflow but couldn’t put together a case unless we had Jira integration. We know the product is viable, but it isn’t yet marketable.

On the other hand, if we show it off to a few customers who all say, “This isn’t solving a meaningful problem. I link these documents to Jira through Confluence. What keeps me up at night is how useless our estimates are!” Here we might pivot to test a novel estimation tool. If the estimation solution gets traction, we can continue to focus our product around estimation accuracy and forecasting.

Our focus here is on testing whether we understand our customers and the solutions they need for their problems. By iterating quickly and being open to pivot, we can reduce risk and maximize value.

Marketability

Once we’ve determined viability, we need to focus on making our product marketable. Meaning we don’t just solve a problem, but we do so in a way that compels customers to buy our product over others or to switch to ours. Here we will narrow in on and focus our product features around our differentiators. Let’s say our core differentiator in our product management suite example is an “Intelligent Estimation Assistant.” Now we need to support that showpiece so we can lift it above the crowd of competitors! We’ll need all the basics of Kanban and Scrum project management. But we’ll want to find all the places where this fancy estimator can make an impact. Of course, it will be used in planning, but can add value to forecasting, roadmaps, and status reporting. If a feature isn’t necessary to lift the estimator above the crowd, we should likely defer it.

I mentioned above that we would need essential Kanban and Scrum project management features in our imaginary product. These features are the table stakes set by the market. Whenever we are operating in a mature market alongside competitors, there are likely minimum sets of capabilities we will have to implement in our product. The key here is to do just enough work on these features at this stage and not too much. It’s improbable that we will solve digital Kanban boards 10x better than anyone else has already. But we do have a shot at a 10x better estimator! That’s where we will get the return and how we will break into the market.

We will start figuring out what’s working and what isn’t in our sales, marketing, and distribution strategies during this stage. As the product becomes more marketable over time, we also need greater clarity around segmentation and cohorts. So far, in our example, we have been targeting SMBs. We’ve noticed that the larger firms aren’t as inclined to migrate from their current provider to our product. They’re entrenched in contracts with sweet scaling deals and have larger organizations that are more costly to disrupt. We can either address the problem directly by creating migration tools or build a strategy around startups, OSS, and small firms. The latter will require effective targetted advertising, where the former preserves our direct B2B sales approach. While paid marketing is less costly than direct sales, the larger customers might be more lucrative and stable.

Depending on our product’s nature, retention, and other engagement metrics, will matter more or less. However, we will always care deeply about the cost to acquire and the customer’s lifetime value. Our product’s features need to support the market segment we are targeting. Our distribution strategy needs to be competitive and aligned. While we won’t solve all marketability problems during this stage, we must have a marketable product at the end. We will also need a scalable product before we can open the flood gates of growth.

Growth

Coming into the growth stage, we have an obvious market fit. Something we do is or is nearly 10x better than our competitors! That’s great, but now we need a significant share of the market. We’ve pumped up our differentiator, and we’ve put up the table stakes. Where we go from here depends on specific circumstances. Generally, we will be doing some refinement and adding features that bring new kinds of customers. The first thing we must figure out is what is in the way of our growth.

• Is our market segment tapped out?
• Have competitors released features that compete with our differentiators?
• Is our product too far out of feature parity with entrenched competitors?
• Is our market too competitive?

Answering these questions will guide us toward continued growth. We may need to iterate on our pricing model or distribution strategy or develop a new 10x feature. And sometimes, the best solution is to either scrap it or just let it ride out in a sustain stage.

The growth lifecycle stage is also when we will want to optimize our development processes, teams, and support infrastructure. Optimization is part of what it means for our product to be scalable. How will we scale:

• Customer support?
• Localization?
• QA?
• Legal?
• Marketing?
• Sales?
• Engineering?
• IT Infrastructure?
• Monitoring?
• Product Ownership?
• Portfolio Ownership?

We will need the fortitude and humility to split our product into multiple products with dedicated product owners and teams in this stage. I believe it’s Roman Pichler who advises, “Split the product, not the product owner.” The complexity that comes with growth will demand our management. We will need to put the processes, structure, and culture radiators in place to keep things aligned, transparent, and productive.

Final Thoughts

Thanks for sticking with me until the end! I’ve enjoyed the chance to get the fundamentals of my product ownership approach documented. It’s far from comprehensive, but I think it captures the ideas and processes that drive me.

My last word of advice to those in product ownership roles is this: Do not wait for other people to make hard decisions for you. Sometimes, the best choice is to pull the plug. Be the one who brings that conversation to the table first. Be known for timely pivots. Don’t be Captain Ahab.

This is an exciting role to fill, whether a traditional or a hybrid position. Good luck and have fun!