How does a product manager without a technical background manage a technical product? After six months figuring this out I think the answer is ‘the same way they’d manage any other product, only more so’. Let me explain.

How does a product manager without a technical background manage a technical product?

Product Management: First Principles.

I’m the Product Owner for the Ministry of Justice’s Cloud Platform, providing digital by default public services with modern infrastructure as a service and web operations. I’m not a Technical Product Owner (i.e. I don’t have a background as a Web Operations Engineer) and was concerned that this would limit my ability to manage the product. Being so far out of my comfort zone has forced me to revisit my product management first principles. For me product management is about:

  • starting with user needs
  • challenging assumptions
  • empowering your team.

My concern has been that my lack of technical understanding is a blocker to all three of these principles. My boss challenged this assumption and suggested that my lack of technical knowledge may in fact be a strength, so I’ve taken these general product management principles and interrogated them in more detail using the definition provided by a specific framework.

Product Manager + Scrum = Product Owner

A product manager working within a scrum framework is called a Product Owner, and Product Ownership is relatively well defined. Here’s a diagram I’ve adapted from a blog post by Roman Pichler, showing what being a Product Owner entails (and situations in which you may not be given the chance to truly be a Product Owner).

Product Owner diagram by Scott Colfer

Vision

You can see in the diagram above that a Product Owner sets the vision for their product. This requires them to define:

  • their users
  • the needs of their users
  • the product itself
  • the value of that product to the organisation.

A good vision showcases a product team’s understanding of their users’ needs and helps defend against forces attempting to distract you from fulfilling these needs.

A vision is not simply a place to record the highest paid person’s opinion (HiPPO) . . . a Product Owner should be empowered by their organisation to challenge HiPPOs (based on the Product Owner’s insights into users’ needs). There’s a good chance that in setting the vision for their product a Product Owner will need to challenge their own assumptions and those of their colleagues. A good vision showcases a product team’s understanding of their users’ needs and defends against forces attempting to distract you from fulfilling these needs.

Strategy

The product roadmap is a Product Owner’s tool for creating the strategy by which the product will move incrementally closer towards the vision, describing these increments in as much detail as certainty allows.

Senior Product Owner

You may be asked to look after multiple products as you become more experienced, given a title something like ‘Senior Product Owner’. If this happens then you’ll be much less ‘hands-on’, possibly looking after just the vision and strategy whilst delegating the tactics to more junior ‘Feature Owners’ or ‘Component Owners’.

Tactics

The product backlog is a Product Owner’s tool for collaboration with their development team, turning the vision and roadmap into incremental product development goals explained through user stories that the team can understand and break into tasks on their sprint backlog.

You might find yourself working on the product backlog with little influence over the roadmap or vision. This is OK (and fairly normal) on a mature product (where you may be managing a single feature amongst a much larger piece of software) but if you are Product Owner for a new product in which you and your team are setting the core features and you are not empowered to genuinely set the vision and strategy . . . then you may have a problem.

Ignorance is bliss

So, back to the MOJ Cloud Platform. Can I, a non-technical product manager, add value to a team building a web operations and infrastructure platform?

The answer is ‘yes’ . . . in fact being non-technical is a strength. Collaboration between me and the development team becomes essential if , for example, we’re to create a meaningful product backlog (‘backlog refinement’ is the name given to this activity within the scrum framework).

A non-technical product manager working on a technical product forces a team to genuinely work with agility and to do product management properly.

In the past I’ve been guilty of holding on tightly to backlog refinement to the extent that I probably missed out on valuable insights from my development team. Having been pushed outside of my comfort zone by working on such a technical product, I need to focus on users and rely on the development team to develop solutions to their problems. I really have to collaborate with my team in order to create a meaningful product backlog (as well as genuinely empowering them to take complete ownership of their sprint backlog). A non-technical product manager working on a technical product forces a team to genuinely work with agility and to do product management properly.

My job is to build empathy with our users, build and defend our vision, and present the development team with well-defined user problems to solve . . . their job is to solve these problems using their wealth of technical skills and experience. My technical ignorance has been a blessing in disguise. The last thing that a team of excellent technical specialists needed was another technical specialist and instead I’ve (hopefully) brought the thing that’s most valuable about product management: the voice of the user.