Problems should be the foundation of product development

We’ve all been to those planning meetings where the conversation starts to go on a tangent and the team starts suggesting ideas that don’t actually solve the problem that you started talked about. I like to call them headless ideas. And as the person leading the meeting, you have to go into damage control. It starts with a delicate dance of slowing the current momentum & corralling the conversation back to the problem.

Why and how does this happen? So much of product management glorifies coming up with great ideas and giving feedback. Also the wider you go in the organization combined with the closer you get to the pixels; the more feedback you’re going to get.

The best arsenal you can have is to be armed with a clear problem. Problems are at the core of product development. You need to know what you’re solving and who you’re solving it for. Problems should be scrutinized over even more than the features or solutions that would solve them. If you don’t get the problem definition right, you’re putting the cart before the horse and everything that comes next is probably wrong.

You want your problems to beget effective solutions. Then be lean about executing solutions aimed at solving the problem. Otherwise you’re just shipping ideas or solutions to problems that your customer might not care about.

Some problem statements

Problem statements should be from the user’s point of view. Often times we get trapped by stating a problem that the business has; which can lead to a lack of market. Let’s look at a few examples where I take a guess at the problem statements related to features:

Facebook newsfeed — “I don’t have an easy way to see what all of my friends are doing without going to each of their profiles separately which is inefficient”

Nest smoke detectors — “I hate the annoying chirp my smoke detector makes when the batteries are dying.” or “I wish Nest adjusted the temperature for the rooms that I’m in and worried less about ones I’m not in” Since your thermostat is usually only in one room of the house, the smoke detector aims to solve that problem.

Asana — Let’s be clear. I ❤ Asana. When they redesigned their service to be “beautiful” I imagine they took a page from Slack and stated the problem as “Project management isn’t fun.” I’m not sure how user centric the problem statement could have been, which is why I’m not sure it was worth the investment. I’m truly curious what kind of incremental gains they are seeing.

I’ve noticed more people talking about this approach recently; Nils Davis at Innotas wrote about loving the problem, not the product. Marc Anthony Rosa, product creator at Buffer, mentions that every great product solves a painful problem. Sean Shadmand talks about tough vs. hard problems. Probably because there are lots of things that go into curating a good problem: how your company handles product development planning, how you structure your company, how you handle incoming feedback, how you talk to users about that feedback. In this piece, I’d like to start a conversation about at least two.

How to structure your company

In my experience as a product manager at companies like LinkedIn, Zynga, AOL Instant Messenger and currently at Kifi; you’re required to wear a handful of hats under the product manager title. They include but are not limited to: product mgr, project mgr, QA tester, marketer, business development manager, front end engineer, analyst, & customer service representative. Teams generally consist of 8 engineers, 1 PM, and then half a designer, a quarter of a QA, and a tenth of a customer service representative.

A few months ago I had a fantastic conversation with Jackie Bavaro, PM at Asana and Co-Author of “Cracking the PM Interview” about how product and design roles are managed at Asana ….. and it was unlike any company I had ever worked at.

Jackie mentioned that the company has 4 product managers and around 12 designers. WHAT?! A 1:3 Product Manager (PM) to Designer ratio?

With only 4 product managers in a 200 person company, all of them are generalists. But still …. 4 PM’s at that large of a company? How was their product development process different from other companies? How do they manage to stay ahead of engineers? Jackie explained that product managers are responsible for thoughtfully & strategically curating the problems that need to be solved. Then bring the problems to your designers; not solutions, not wireframes or feature ideas – hand them a clear, thoughtful problem. Designers,then, focus on ideas or features that serve as solutions to those problems. PM’s are stakeholders in selecting which solutions becomes features, but ultimately the majority of the details of feature development are directly in the hands of design and engineering.

When I first heard this, I thought that it was a little unnecessary to have that much focus on prioritizing problems. Can every new product innovation be defined by a problem? Who’s problem do you solve; a user’s or the companies? Can you really fill up a day thinking about problems? How can you let go of the “fun” part of product management which is coming up with great ideas? But the more I started thinking about it, the more it made a lotof sense. I think it can be broadened a bit to say bring your “team” problems. Make sure all major players, including yourself, are a part of the solution brainstorming and selection. But this set up gives everyone more autonomy and in theory gets higher quality gets creativity around your biggest problems and goals.

How to make problems central to your product development process

Not every company is at the size Asana is so you can’t afford to have product managers solely dedicated to problem identification. Here are a few areas of product development and daily life as a PM where focussing on the problem can help:

Product planning should include problems in the discussion

Zynga, specifically the team I was on at Cityville, integrated discussion about problems into their core product development process. Each quarter started with 3 KPIs and our roadmap was framed around that. To be clear, the KPI’s were not problems. They were, albeit broad, metrics or goals chosen to help us measure if we’re solving problems. Something like increase Net Promoter Score to 30 or get DAU to 17M. These were derived from trends in our rigorous daily reports and weekly meetings — meaning every PM was already very aware of the problems within the game’s ecosystem. More importantly, the regular vocabulary of analytics driving product management gave us a natural language to talk about whether or not we were solving our problem.

The best part is that product managers would sit in a room every quarter alongside game designers to discuss with features & fiction within the game that would solve those problems & move those #s.

Getting to the MVP

We were building a feature within Kifi in which users create a team. Of course we struggle with when to release it vs adding in just a couple more features. One of the areas that was a hot topic of debate was around making it easier for people to get their coworkers to join the team.

Lots of companies have team like infrastructure on their site like Trello, Github, Quip, Dropbox and Asana. So every single team member had opinions on how Kifi should do it. We should create a URL with an auth token that people can paste it in their company chat [Dropbox]. Build email domain mapping so that when people join Kifi using their company mail, they are automatically put on their company team [Quip]. We should redesign the invite email to be simpler [Asana].

All of these are great ideas, but they solve COMPLETELY different problems.

I took a step back and realized that all of these are great ideas that would certainly help improve team density, but they solve COMPLETELY different problems if a user was describing the problem(s) to us. When you’re nearing the finish line & dealing with scope creep, it’s helpful to have a clear problem that you can revisit whenever something gets thrown your way.

What was the user’s problem? “I don’t know how or why to invite my teammates” (% team owners inviting). “It’s too much work to send invitations to my entire team of 25+ people” (invites / inviter). “My coworker never got the email” (invite CTR). “Someone told me to join Kifi over lunch and now I can’t find my team” (# of users joining a team on Day 2+). Each of these problems would lead to different features and save wasted feature development cycles.

Fortunately I work with a great team of engineers at Kifi that I can often hand the problems too and they return with great solutions.

All brainstorms should start with discussion about the problem

Whenever you go into a brainstorm, there are rules like: Don’t critique other’s ideas. It’s about quantity not quality. Don’t edit other ideas, build on them. But that can be difficult and unproductive when you feel like the ideas aren’t solving a problem that your company has or that user’s will even care about.

Brainstorms should start with a clear problem that you’re trying to solve. Use the problem as a litmus test for the ideas coming out and refer to it when you think it will help get more actionable ideas to be discussed.

1-off ideas in the hallway

If you still don’t think you’re a problem manager, think about all the times you’ve had random ideas are thrown at you from summer interns to the CEO. It’ll happen when a competitor releases a new feature, when the CEO comes back from holiday break & when customer support forwards on some awesome user feedback. Anytime someone comes to you with an idea, try responding with “What problem is this solving?” Getting other people into this frame of mind means that they next time they come back to you, they’ll already have this answered.