
This is the third in the series of articles on the product operating model. To recap, it has three dimensions.
- The right problems to solve
- The right solutions to the problems
- Solutions delivered the right way
The previous article was on product delivery. Here is how to discover the right solution to a problem.
Assumptions
The right problem to solve has been identified. A good practice is to formulate the problem as an OKR (Objective and Key Results).
- Objective is the qualitative problem description of what needs to be achieved and, importantly, why—the rationale
- KR is an outcome and how we measure the progress towards the Objective
The empowered product team has been asked, within the strategic context, to discover and deliver a solution that is valuable & usable for the customers, feasible for us to build and maintain, and viable for our business.

As noted in the previous article,
- the team will iterate between product discovery and product delivery
- the two intertwined disciplines are fundamentally different

Agile assumed that someone was doing that front-of-funnel part, generating and validating ideas, and instead optimized the production of software. Yet, that piece has been lost along the way, as companies believe that Agile is all you need to do successful software development. So, many product managers in Agile organizations still operate with this Waterfall mindset.
Melissa Perri, Escaping the BUILD TRAP p. 26
Melissa Perri here stresses the importance of a structured and disciplined product discovery.
Product discovery
The discipline of product discovery is a deep and branched rabbit hole in its own right. In 2022, I wrote this article on the subject, pointing to some of the many discovery techniques.
At least these four books should be on your shelves.
One hallmark of the product operating model is that product teams interact frequently and directly with customers, not via layers of customer proxies.
During customer interactions, the product team will use experiments to test hypotheses on value (is it perceived as valuable to the customer?) and usability (is it easy for the customer to use?). The solution hypotheses must also be feasible to implement, support, and be viable for our business.

Tendayi Viki, Pirates In The Navy: How Innovators Lead Transformation
There is no one-size-fits-all product team structure, but for the sake of argument, let’s use this one from Marty Cagan to illustrate the focus areas:
Product manager
The product manager is responsible for the solution to be valuable for the customer and viable for the business.
- Deep knowledge of the Customer – meaning the need to become an acknowledged expert on the customer: their issues, pains, desires, how they think, how they work, and how they decide to buy. Of course the PM must also be an undisputed expert on your actual product.
- Deep knowledge of the Data – being comfortable with data and analytics.
- Deep knowledge of your Business– understanding how it works and the role your product plays in your business. This includes knowing who the various stakeholders are and especially learning the constraints they operate under.
- Deep knowledge of your Market and Industry – covering not only your competitors but also key trends in technology, customer behaviors and expectations and following the relevant industry analysts. The PM may be supplemented with what are called domain experts or subject matter experts.
To be successful, a product manager must be the very best version of smart, creative, and persistent.
Marty Cagan, INSPIRED p. 41
Product designer
The product designer is responsible for making the solution usable to the customer.
- Product Discovery – meaning product designers continuously collaborate with product managers and engineers, from discovery to delivery. The product designer sits side by side with his or her product manager, a full partner with the product manager on product discovery. The product designer is deeply oriented around actual customers and the value their product brings to those customers.
- Holistic User Experience Design – meaning any way customers and end users realize the value provided by your product. It includes all the touchpoints and interactions a customer has with your company and product over time. Good product designers think about the customer’s journey over time as they interact with the product and with the company as a whole.
- Prototyping– meaning the use of prototypes as their primary canvas for communicating ideas, both internally and externally. They are generally comfortable with many different prototyping tools and are able to apply the correct one for the task at hand.
- User Testing – meaning that product designers are constantly testing their ideas with real users and customers. User testing is broader than usability testing. Product designers and their product teams utilize the opportunity to assess the value of their ideas. Will customers use or buy the product and, if not, why not?
- Interaction and Visual Design – where interaction design generally includes the underlying conceptual models and visual design includes composition, typography, and how the visual brand is expressed. If building devices such as consumer electronics, there’s another critical dimension to design – industrial design – which looks at materials and design for manufacturing.
Apple is one of the most valuable and design-conscious companies on the planet; yet few tech companies understand the importance of design talent.
If you’re doing products for businesses, then this is one of your best competitive differentiators.
Marty Cagan, INSPIRED p. 53
The Engineers and the Tech lead role
The engineers are responsible for the solution as feasible to build and maintain.
- Strong relationship—meaning there’s probably no more important relationship for a successful product manager than the one with your engineers.
- As much latitude as possible – meaning that you let the engineers come up with the best solution.
- The Tech Lead Role among the engineers is important – meaning that the Tech Lead also has an explicit responsibility to help the product manager and the product designer discover a strong solution.
Marty Cagan, INSPIRED p. 59
Additional roles, often across product teams
A future article might address some of these roles.
- Product Marketing Manager
- User Researcher
- Data Analyst
- Domain/subject-matter experts
- Delivery Manager
- And ..?
Example from Grundfos
As an external consultant in 2022, I worked with Grundfos on validating an ambitious business model (that I coined “Future Reach”) based on an advanced digital self-service offering, providing customers with a full and seamless end-to-end customer journey, selecting, configuring, purchasing, commissioning, and servicing full Water Solutions. The full case is found here. Specific details cannot, of course, be disclosed.
My approach was to utilize (some of) the principles from the product operating model. I’ll return to this case in an upcoming article on what problems to solve. I’m here assuming that we have decided on a problem to solve.
Background
Before initiating the business model validation initiative, the Grundfos division had done the initial homework, running customer exploration experiments, such as customer interviews, to provide insights on customer opportunities (jobs/needs, pains, gains/desires).
These customer insights, combined with the strategic context, form the basis for the Future Reach business model hypothesis.
At a point in time, we came to a business model hypothesis that needed validation:
“We believe that we have a valid Future Reach business model that is desirable for our customers, feasible for us to implement and operate, and viable for our business.”
What was more natural than using the Business Model Canvas to model and validate a business model?
The Business Model Canvas can logically be grouped into three hypothesis areas: desirable, feasible, and viable.

I’ll here only focus on the desirability hypothesis.
Testing the desirability hypothesis
Desirable means that what we provide to the customers
- is valuable
- is usable
In other words, we need a strong product/market fit.
Our next step was, based on the earlier collected customer opportunities, to decide on
- the customer segments/profiles that we want to serve
- our value proposition to these customers

Inspired by Dan Olsen’s The Lean Product Playbook
The Value Proposition Canvas helps us structure exactly that.

Customer profile: we believe that we
- are addressing jobs/needs that matter to customers
- are focused on pains that matter to customers
- are focused on gains/desires that matter to customers
Value map: we believe
- our products and services solve high-value customer jobs and needs
- our products and services relieve top customer pains
- our products and services create important customer gains
We’re not done yet, having populated the Value Proposition Canvas. It still represents our assumptions. We need to go back to our customers and test the validity of these assumptions.
Realistically, we cannot and should not spend the customers’ and our own time testing all assumptions.
We’ll prioritize planning and doing structured assumption tests on important assumptions for which we do not yet have sufficient evidence to support them.
For the important assumptions with seemingly a high level of evidence, we’ll challenge ourselves on the validity of the evidence.
Now having decided on a few highly prioritized assumptions, the next step is to design and run the assumption tests with the customers.

Inspired by Testing Business Ideas
Because Future Reach is a digital offering, we prioritize mostly using visual means to test our assumptions with customers.
The product team prepared a clickable mockup to be used during the interaction with the customers.

Inspired by The Lean Product Playbook
As you’ll recall, the product team needs direct access to customers. Grundfos arranged exactly for that. A group of customers were provided to the product team. Before moving on, I’ll share with you the energy and excitement such a direct interaction sparked.
The customer: “So great that we can have this kind of interaction with a highly knowledgeable team seeking to discover solutions to problems that matter to us. We’re also a bit humble, being asked to voice our opinion in this early stage of the product development.”
Team: “This kind of direct communication with a brief feedback loop expedites the process of validating the solution hypothesis before requesting funding to put it into action.”
Customers are happy, the team is happy—what’s not to like?
Discipline
For us to gain the most insights, we needed to act structured and disciplined. To support this, we chose to use the test- and learning cards from Testing Business Ideas.
In this way, we forced ourselves to come prepared for a focused dialogue with the customers, and we forced ourselves to capture and reflect upon learning in a structured way.


Wrap-up
Done right and disciplined, product discovery helps us ensure that we choose to implement the best solution to the given problem, meaning that the solution
- is valuable to the customer
- is usable for the customer (and users)
- is feasible for us to implement and maintain
- is viable for our business