Product Model Advisory

The best product companies operate differently from the rest. They have different product cultures but apply the same principles. One key principle is that the product teams in the companies are empowered with problems to solve and accountable for results, not outputs. This forms the basis of the Product (Operating) Model.

I give advice (to those who ask for it) for many topics, since I am fortunate enough to have seen and learnt many things throughout my career. When Marty Cagan presented his and his team’s take on a model that covers the key aspects of product development, I felt it encapsulated and highlighted my knowledge of the area. The step to calling oneself a Product (Operating) Model advisor and Product coach was not a big one for me, since I have already helped numerous organisations to take a more holistic approach when creating products and services.

The Product (Operating) Model is almost an anti-process, because there is no right way to create successful products. But, there are mindsets and principles. One key principle is that all individuals and all teams in a product-selling company are working on their products, regardless if they are “just” in the IT department or in HR. All of the organisation has to change their way of thinking about product development, to start seeing it as a great collaborative effort aiming towards a successful outcome for the organisation, the individuals within and the customers on the outside.

Apart from changing how you think in the organisation about product development, there are three more areas to cover to move towards the Product Model:

  • Changing how you build things
  • Changing how you solve problems
  • Changing how you decide which problems to solve

The first one tackles the fact that however well you build your product, what matters more is how agile you can be when building and releasing. Principles of how to do this are listed under ‘Product Delivery‘ below.

The second one tackles the fact that it is easy to come up with ideas, but harder to know which ideas that are worthy of implementing. Principles how to do this are listed under ‘Product Discovery‘ below.

The third one tackles the fact that serving only the business will get you so far, what matters more is how you serve your customers. Principles how to do this are listed under ‘Product Strategy‘ below.

Since my experience differs a little bit from Marty’s, I have modified his original list of principles slightly, mainly adding the importance of good collaboration.

Product Strategy

  • Keep focus on the huge impacts, say no to not worthy ideas
  • Powered by insights to get serious about keeping focus
  • Build transparency to build trust
  • Make experiments to manage the risks
  • Structure organisation for the wanted outcomes
  • Improve collaboration to increase effectiveness and efficiency

Product Discovery

  • Understand the problem and the solution to minimise waste
  • Improve collaboration to increase effectiveness and efficiency
  • Test ideas responsibly
  • Continuously address risks to create the best impact and outcomes

Product Delivery

  • Iterative and experimental thinking to increase feedback and lower risks
  • Small, frequent, uncoupled releases to increase feedback and lower risks
  • Evolutionary development to minimise waste
  • Improve collaboration to increase effectiveness and efficiency
  • Continuous integration and releasing to have agility / turn on a dime
  • Continuous qualitative measuring, monitoring and telemetry to find outcomes fast

As part of my Product Model Advisory, I often run a training for the product organisation to convey the why’s behind the new way of working. Check out the Progressive Product Thinking training here.

Case study: Product Discovery with the Holistic Product Discovery Framework

A Playbook from King

Playbook for the team at King

Case client

King

Background

A team whose mission was to build and maintain a game operations platform for operators and developers in a large gaming company had realised a year back that they needed some developer tools for building applications for that platform. This realisation came through feedback that it was hard to start creating applications, regardless of the knowledge and experience of the developer. The idea for tooling and support for the platform developers to fulfil their needs was born.

Assignment

I was assigned to help out with the second stage of the project, when the team had understood there was a great need for discovery to make sure they built the right thing. Since I was meant to help out over a longer period of time, the Discovery process I created was just shared briefly as a concept to the team, and then I gave them one part of the map at a time so not to overwhelm them.

Activities

  • Discussions with the team to understand the product and process needs
  • Creation of a process together with the team while we together performed their needed Product Discovery. We did this so that the team could use the process after I was gone from the project
  • Using the Holistic Product Discovery Framework as a structure, which was something everyone in the team understood after sufficient training.

Delivery

  • A way-of-working with ideas and problems of all risk-levels, including high risk discovery in the form of a open and flexible process structure.

Client benefit

The employees learned the mindset very well along the way and could change the process when needed on their own.

Read a deeper explanation of this case project here