From Solutions to Problems
By: Ryan S.
Tags: Design, Startup, Technology, Product Management, UX

One thing to remember is that “Big A” Agile doesn’t create great products alone. When I say to build a framework, I am certainly not suggesting that you simply adopt Scrum and be done with it. Agility, if anything, has led to a breakdown in how we approach problems. Somewhere along the way we stopped caring about the discovery and started focusing on delivery, because “working software” is better than nothing. Maybe some of us never cared about the discovery, to begin with.

The “working software is better than nothing” principle is true, but also inherently flawed because it fails to mention the critical work before a single line of code is written. The key takeaway here is that “working software” is only valid if it’s solving a problem for someone. Finding the balance for the right amount of discovery versus delivery is both an art and a science.

Personally, I doubt copying a single framework “by the book” works in most organizations. I think it’s important to utilize principles and philosophies from different schools of thought throughout your product discovery and delivery process. You may research and test using Design Thinking, Lean Startup, Scrum, XP — but in the end, you will likely end up with elements of each of these in your framework.

Next, we’ll walk through the high-level stages of iterative discovery.

Understanding is always a good first step

So, you have a structure, now what? Successful problem solving comes down to empathy and framing — and this is often a good place to start. You may already have some level of understanding of where to focus your efforts. But if not, what are the inputs or events that will trigger the discovery exercise?

Typically, these can vary based on your organization’s maturity and what channels are available for your customers to voice their feedback. Here are some good places to begin:

Trending requests by customers and prospects to your Sales and Success teams.

Ideas sourced from a user group, community, or customer forum.

Common RFx questions or requirements from prospects.

Help-desk and support ticket data about common challenges.

Post-mortem analysis of lost prospects and/or churned customers.

Continuous feedback via surveys like NPS.

With information like this available, you can begin to focus your discovery. A non-trivial amount of time should be spent in front of customers and users, listening to their challenges, and framing them in a way that’s consumable for your stakeholders.

If you come from a circle that deals with traditional “projects”, you may think this sounds synonymous with big planning upfront. You’re both right and wrong. This isn’t a typical “plan”, but failing to plan is often planning to fail. There should be some level of strategic thought put into the problems you choose to tackle, and this data simply helps with your prioritization.

Lost in Translation

Keeping in mind the initial channels of input we’ve covered above, you may need to do some translation. Because our user community isn’t exposed to our discovery process 100% of the time — customers and other stakeholders may have become accustomed to making demands. That’s why we often hear things like “build X” or “design feature that does Y” rather than “help me solve challenge Z”.

This is also because customers are great at imagining what they think they want — but really bad at actually knowing what they need. Herein lies the incredibly important step of problem validation. I won’t get into the tactical details, but problem validation can be summed up as translating inputs like “build X” into well-defined and clearly articulated problems, which are validated with the same people who suggested them. And I can’t stress the importance of actual human interaction with your user base through customer interviews, not simply sending out a mass survey.

Take a moment to reflect on your own language as well; this is also important. The terminology used to describe your work, and to describe how you work, can heavily influence the success of the work itself. You’ll want to ensure that when you are customer-facing and trying to validate a problem, that the message you’re sharing resonates across various audiences.

I’ve found writing a glossary to be a useful exercise. You can use this as a tool for translating your product vernacular into simple terms that your customers and other stakeholders will understand — a lingua franca for problem-solving if you will.

There are many ways to generate a good idea

We have a well-defined problem that’s been validated with a segment of the market. So how might we help alleviate this problem? We’re at a level of understanding where we can confidently begin to dial in on potential solutions. And that exact question is actually a great one to pose when kicking off your ideation phase.

Regardless of whether or not you have access to a design team to back you up, I find there are two very different and equally good ways to come up with ideas for solutions. You should aim to exercise a combination of both. The first is done completely alone, or with a very small group. In this method, you can deeply focus on what you know already about the problem, and write various ideas that you come up with.

The second method is to leverage a larger, more diverse set of stakeholders in order to collaboratively bring ideas to the table. This method can take the shape of a facilitated workshop or an informal discussion between colleagues. Either way, different perspectives will shed light on things you may not have picked up in your discovery, and others’ previous experiences will generally strengthen the group’s ideas. It also allows you to see what assumptions are made by those who are not intimately familiar with the problem space.

Being the more creative and fluid phase of the overall discovery journey, I don’t believe there is necessarily a “right or wrong way” to approach ideation. I do not think it matters which method is used first, as long as you’re not doing all the work yourself. The input from others will help validate your ideas, and their ideas will challenge yours in a healthy way. This may even lead you to circle back to a previous stage.

Ideation can and sometimes should be an iterative sub-process

Finally, is good to keep a finger on the pulse of your discovery process. Even during a creative process like ideation, it doesn’t hurt to continually ask a few other key questions to yourself throughout this phase, in order to keep yourself from veering too far off target.