This is a guest post that was originally published by Jen Ruffner on .
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 about.[Tweet "Otherwise you’re just shipping ideas or solutions to problems that your customer might not 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:
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 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 handles product development planning, how you structure your , how you handle incoming feedback, how you talk to users about that feedback. In this piece, I’d like to a conversation about at least two.
How to structure your
In my experience as a product manager at companies like , 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 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 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 I had ever worked at.
Jackie mentioned that the 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 , all of them are generalists. But still …. 4 PM’s at that large of a ? 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 become features, but ultimately the majority of the details of feature development are directly in the hands of design and engineering.[Tweet "Bring your designer problems; not solutions, wireframes or feature ideas."]
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 lot of 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 setup 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 is at the size Asana is so you can’t afford to have product managers solely dedicated to problem identification. are a few areas of product development and daily life as a PM where focussing on the problem can help based on some expert advice from the PMHQ community:
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 sites like Trello, Github, Quip, Dropbox, and Asana. So every single team member had opinions on how Kifi should do it. We should create a with an auth token that people can paste into their chat [Dropbox]. Build email domain mapping so that when people join Kifi using their mail, they are automatically put on their 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 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 has or that user’s will even about.
Brainstorms should 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 the next time they come back to you, they’ll already have this answered.
When you evangelizing and advocating for problems you enable more autonomy throughout more roles in your team. From every angle, you’ll get higher quality ideas from allowing a wider variety of roles within the (customer, engineering, etc.) to successfully join in on those “fun parts” of product development like idea generation.
So much of our job gets described as coming up with ideas & building features. The irony is that we’re the gatekeepers that need to say “no” more often than we’d like. We should talk more about how important identification of problems is to every aspect of our job and those of the people that we work alongside.
About the author: This was a guest post contributed by Jen Granito Ruffner, who currently leads Product at Kifi and has previously worked at , Zynga, AOL, and others. This article was originally published on.