5 posts, 5 years worth of learnings. Posts about mistakes I made, explained, so they need not be repeated. Sub 15 mins reading time each. Bargain.

My name is Lucy Chambers. I have problems.

People are employed in order to come up with solutions. The success of my career will depend on the ingenuity of the solutions I create.

‘Problem definer’ is a role in itself. The most ingenious solution-creators in the world will fall flat on their face if they fail to correctly diagnose the problem that they are solving.

A new role

In April 2015, I started freelancing as a product manager for software companies. Since then, I have been asked regularly (sometimes at least once per week):

“But what do you do exactly? Is that like a project manager?”

The confusion probably arises from the fact that project management is relatively well understood. Project manager is a role that exists in many spheres, both technical and non-technical.

Some roles (including ones I’ve held) necessitate needing to switch hats between product / project management. There are different flavours of product manager, but it is always a distinct role from a project manager.

In a highly oversimplified form, the difference between the two is as follows:

• A product manager is the translation layer between a team of developers and stakeholders*. They define criteria for what needs to be built and why.
• A project manager defines the how and when: e.g. how much money can be spent, when certain things need to be delivered and often staffing.

* Stakeholders in my case are often external clients, but can also be managers and other internal “clients” at the organisation.

How I like to think of my job:

My job has basically three parts:

1. Absorbing huge volumes information in various forms: processing details about a situation and distilling clear problem definitions out of it. This information can be anything from anecdotes and whitepapers to data and process documents.
2. Establishing which subset of the aforementioned problems technology stands a chance of solving (hint: never all of them).
3. Working out a “definition of done” i.e. defining acceptance criteria so that we know when the problem has genuinely been fixed. When person X can do Y - we are done.

The importance of the “definition of done” is that with software - there is always refining and tweaking that could be done to make the feature a little bit better. If we are not careful to define when enough is enough, a feature may be overcomplicated / -engineered / -polished for so long that it becomes irrelevant by the time it sees the light of day.

Combatting information overload

In a nutshell: It is my job to strike an information balance for the delivery team.

I need to ensure that my team is not overwhelmed by unfiltered torrents of possibly conflicting information but also to understand the problem well enough myself to provide them with whatever additional background or context they need to make the right technical calls.

Distilling problems isn’t something that is specific to a product manager role - but in such a role it is one of the primary activities.

I would estimate that the three items above consume 75-90% of a role in the projects I work on (see earlier reference to some downsides of combining project and product management in one role - number of hours in a day being just one major limiting factor).

---

Being part of the solution

I opened by saying that I do not believe it is my role to come up with ingeneous solutions. That does not mean I shirk rolling my sleeves up and doing the hard work. I just think that a single person prescribing a solution shuts out a whole range of possible, potentially better, solutions that would never occur to one person.

In a well-functioning, interdisciplinary team, solution preparation is a team sport involving everyone. The team devises a range of possible solutions and estimates the relative effort involved in delivering each of them.

A product manager’s role is to then take the range of possible solutions and decide which of them most accurately addresses the problem. Together with a project manager, the product manager then has to decide which of the available menu of options is most appropriate given available time, money and desires.

And that is what gets built.

Summary

Product management was the purest embodiment of my passion for “tech translation” which I could find in a job.

I work in the not-for-profit sector and some of the real-world problems we handle are enormous. The only way not to wallow in a mire of despair is to break the beasts down into a series of smaller problems which we can fix one by one.

The sector means I often get to work with stakeholders who are commissioning a piece of software for the first time. They often have huge amounts of subject-matter experience, but are totally unsure of where to start with a software project.

I reassure them that I am going to have to learn their world and they will learn mine. As long as they keep talking to me, we are going to work this out. I am all ears.

Further reading:

• Agile Modelling’s Product Owner definition
• Neo’s breakdown of different flavours of product managers (Archive.org)
• Product coalition’s amazing piece on how product managers spend their time depending on the team they are in

Acknowledgements

Thank you to Amir and Tony for their thoughts on this post and for generally lending me their brains to hash out product stuff!