Whether you work in product management, marketing, or sales, a good problem statement can be very beneficial in helping to define, market, or sell your products.

The other day a product idea was pitched to me which, when described verbally, was one of those ideas that was very complex and difficult to explain. It began to feel like a maze of features which not only overwhelmed me, but bored me. I rapidly lost interest and started to think about other things.

If this sounds like a reaction you often see in your product teams, customers, or stakeholders, then you might need to think about tightening up your message.

I started working with the client to simplify the explanation of the business model enough that people hearing about it would not get overwhelmed.

This was the perfect scenario for a problem statement.

For anyone who doesn’t know what a problem statement is, it is the basic problem that the market is experiencing which you feel you can solve with a product.

Writing a problem statement is not an easy task. I have found that it works best as a very simple statement without caveats or descriptions. When I ask someone to write a problem statement the first time, they invariably try to use their solution as the problem.

Bad Problem Statement: “Cambridge needs to create a congestion zone and charge drivers for driving within that zone.”

By using their solution as the problem statement, they have not only avoided acknowledging the actual problem they are trying to solve, but they have essentially ended any discussion around how to solve the core problem. If the audience doesn’t agree with their solution, there is no empathy remaining around the need to solve the problem that still remains.

Good Problem Statement: “Traffic into Cambridge can come to a standstill, usually in the mornings.”

A good problem statement explains in very basic terms what the core problem is. With luck, this results in an ‘A-ha!’ reaction in the audience which is critical if you wish to guide them down the right path towards creating the right product or selecting your product as their solution.

Real World Case Study

Chances are that the makers of Google didn’t sit down and say “lets build a search engine” just for fun. They probably first identified a problem in the market such as “finding anything on the web is difficult.” Their solution was “build a search engine.”

Now that the problem statement and solution statement have been sorted out, it is a good time to begin listing the features and benefits of your solution. This is another situation where people often mistake one concept for another. Your feature is not inherently a benefit, and the benefits that your solution provides don’t count as features.

I prefer to list the features and benefits in table format with features in the left column and benefits in the right column, each benefit aligned with a specific feature. The hypothetical Google features and benefits might read:

Problem: “Finding anything on the web is difficult.”

Solution: “Build a search engine.”

  • Feature #1: Robots scour the internet for words and phrases
  • Benefit: Website owners do not need to submit their sites for inclusion into search results
  • Benefit: The latest versions of website are always searchable
  • Feature #2: Words and phrases on the internet are indexed into a database of results
  • Benefit: Searches can occur fast and results displayed almost immediately

If you take this example and use it as a template, keep an eye on how often you find yourself writing a solution in the problem field or a benefit in the features field. After a bit of practice, you can get your product idea clearly defined and communicated.

Today we officially launched Mali Developer Center at ARM TechCon3 in San Jose, California.

This portal brings together a variety of resources and tools for software engineers writing code for the ARM Mali Graphics Processing Units.

When I began the process of creating this website, I wanted to use it as an opportunity to step back from our standards ways of doing things and see what we might be able to improve both in strategy and implementation. With an already overworked website team in the company, a design team without sufficient time to perform user interface design, and a tight schedule and budget, I decided to see what options existed outside of the company’s resources.

Using references from various colleagues and friends, I started exploring external web design agencies with an eye towards finding one that understood what it meant to design for the audience. In this case, I needed a website that was targeted towards engineers and contained no marketing aspects. The three agencies chosen did basic investigation into what our goals were for the website and identified the target audience.

One design that came back really stood out as exactly what the target audience would understand. The agency, Overland Agency in Portland, Oregon, was awarded the job and began work right away.

The first thing that struck me about Overland Agency was that they did all of those ‘discovery phase’ steps that we’re all supposed to do before embarking on a software/web project but never think we have time to do. The first thing they did is interview some people who represent our target audience (software developers), then they worked up some user personas for the website and example workflows that those users might require. Finally we got final mockups and wireframes against which I held some usability tests to work out the remaining kinks in the overall design and navigation.

We then had a few surprises internally and I found myself needing to hire Overland to actually create our website on top of doing the design work. They achieved greatness, thanks to their most senior engineer giving up his weekends, and only three months from the start of the project we were able to launch a superb website that provided everything our customers needed for developing code on Mali GPUs.

Article about Mali Developer Center

This project really showed how much time and effort can be saved in a project by doing advance discovery work at the beginning of a project. It might feel like a stressful delay to the project kick-off at the time, but getting it right the first time will help to ensure an on-time and (mostly) on-budget product launch.

And if you suffer from insomnia, you can watch a video of the Mali Developer Center in action. (Author’s note: I had never realised how boring I am! Ugh!)