David Tuite
TwitterRSS Feed
The simple value of writing down the problem

The simple value of writing down the problem

One of the harsh lessons I learned in my first 6 months as a product manager is that situations can run off the rails very quickly when there are multiple people involved and everyone is running full speed trying to fix a problem.

When it feels like the world is ending, it's tempting to rush in and start trying to fix the problem as quickly as possible. Often, the problem is not even well understood but people will start trying to fix it anyway.

PAGEVIEWS HAVE FALLEN OFF A CLIFF IN THE LAST WEEK!!! Ok... that does sound like a problem, but what kind of problem is it? Perhaps Google changed their ranking algorithm.. perhaps we rolled out a bad code change and de-listed several high traffic pages, perhaps someone wanted some pages de-listed for a good reason and we just don't know what it is yet.

It sounds silly, but when everything is on fire, simply writing down the problem can go a long way towards fixing it.

There are three specific benefits which arise from writing down the problem:

  1. It keeps everyone on the same page
  2. It helps new people get up to speed quickly
  3. It records history

It keeps everyone on the same page

How many times have you been in a meeting where something like the following conversation happens:

Mary: "This solution will easily scale to 10k hits a week"
Jim: "Great but we need something which can handle 10,000k hits per week"
Mary: "Are you sure? We saw 10k hits last week."
Jim: "No I'm fairly sure John told me it was 10,000k hits."
Everyone else: 🤦‍♀️

The whole meeting is now stuck because nobody can tell what the next steps are. They can't even agree on basic facts about the state of the world.

Don’t spend your time going back and forth like this. Put your problem in a document and use it as the source of truth for all of the parameters of the problem, share it on the screen in the meeting and help everyone move onto the important stuff.

To be a viable source of truth, your document must be a) correct and b) fresh. This means you have to fill it with facts (rather than conjecture) and keep it updated. If a fact turns out to be false, replace it with a new fact.

It gets people up to speed quickly

Not everyone who might be involved in solving a problem will be an expert on the problem space. In any complex scenario, many people with many different roles will be involved before the problem is solved. Before a simple new feature reaches production, a security engineer might have to review the architecture, a legal person might have to sign off on it and a networking engineer might have to firewall it.

Lots and lots of people are involved when you’re trying to solve a complex problem in a large organization and they’ll each have their slice of knowledge. When you have a document with a diagram and a description of the current state of affairs you can let anyone read it for 5 mins and know enough to give you their perspective.

Without it, you’ll have to verbally describe the situation 10 different times to 10 different people and you’ll leave out details and make mistakes.

Even worse, people will hear about the problem second hand with many missing details and form their own opinion based on mistaken information. When you have a document to point to you can nip this in the bud.

It records history

This sounds mundane, but it's incredibly powerful. The only way we can learn from our decisions is by being able to review them. By recording the decisions that were made in response to a problem and understanding why they were made, we can retrospectively look back and learn lessons that can be applied in the future.

At some point in your product management career, you will be part of a product that fails to meet its goals. When this happens, others will have legitimate questions about why various decisions were made throughout the development of the product. When you've recorded context that existed when decisions were made, it's very easy for other people to understand why things happened the way they did. When you have nothing written down, it's all too easy to guess at what was happening and get it wrong.

Most good document stores have some type of versioning these days. Confluence has it, Google docs has it, I’m sure many other products have it. You can use these documents like a living history store where you can go back and figure out when you learned a specific piece of information or when you changed your mind on a decision.

If you never wrote down the problem in the first place then no document store in the world will be able to retrieve it for you!

In the early days of my product management history, quite a few situations I was involved with became confused because there was no simple record of the problem being solved and the various ways to solve it. I learned this lesson the hard way.