My favorite tools and methods for product discovery

Knowing what and when to use them (and how to avoid common traps)

Used with permission from Pexel

Is Technology the Solution?

Technology can be an incredible enabler for teams looking to find new solutions to sticky, important problems. But sometimes I see teams and organizations rushing to put the technology ahead of other ways of solving the problem because it feels like the right thing to do.

How can you counter this impulse to digitize solutions? How can you keep stakeholders at bay who are eager to have a flashy and exciting way? We’ll explore those questions and more here. But first, a story.

One of my favorite examples of how a team started with a goal of using technology to solve a problem but ended in a very different place comes from the medical industry. A team that was working to re-imagine the MRI experience for kids — an experience that can be traumatizing and painful — had a hunch that new technology and designs could alleviate some stress. But rather than work to build new machines (they are expensive!), they began exploring other hypotheses and ideas about how to shift how kids experienced the machine rather than changing the machine itself.

Cited from the Newsroom of GE Healthcare

So many companies and teams would have jumped to a technical solution but this team didn’t. They went old-school: paint, decals, music, lights, acting, and smells. They made it an adventure for kids. It was an incredibly human solution to what presented initially as a technological one. (This story can be read in more detail in Creative Confidence by Tom and David Kelley).

What did the team do that helped them to avoid the “default to tech” approach?

• They began with empathy.
• They identified different forms of risks and iterated their way through different versions to unpack the assumptions behind each category of risk.
• They identified key stakeholders — not just the “user” but those who would influence the user and their peers who needed to be onboard to implement the solution.
• They tested small. They ran a pilot that significantly reduced the risk and, as they gained new insights into what was needed in the solution, had a growing cohort of backers and supporters.

The most important takeaway is that before you define a problem statement or recruit people to develop a solution to a problem you’re trying to tackle, start with a goal to empathize and understand the problem. There are many tactics for doing exactly this — from a Design or Discovery Sprint to a wide array of user research methods. The mistake I see teams make isn’t so much that they’re skipping this research, but they’re going it to it assuming that the solution will be digital. That misses the point in many cases.

Spend more time with the people whose practices you’re trying to help. This is essentially the difference between having a “data driven practice” and applying a strategy of “practice driven data” as brilliantly researched by a group working with Chicago Public Schools.

When Technology is the solution

If you’re at a startup or a tech product company, your approach and needs are different from a larger enterprise, non-profit, or government organization. This is about those latter contexts when the communication channels and stakeholders are equally as important as getting to problem/solution fit.

Where do you need to focus in a larger enterprise at the beginning stages of discovery?

• Vision and alignment. What is the story of the solution you are creating? How will the lives of those you’re trying to help be different because of what you do?
• Communication channels and existing support. Who are your partners, allies, and supporters in this work? Finding alignment isn’t just about about picking an org priority and saying “this aligns.” Build relationships that can evolve conversations from ambiguous goals and priorities to shared outcomes and sense of responsibility.
• Problem validation. Even with a vision and supporters, it’s possible you’ve found a niche that just isn’t that important in the big picture of what others are trying to do. You need to be confident — and have the evidence to back you up — that the problem isn’t just real, it’s causing pain and holding people back from being their best selves.
• Solution validation. There are many ways to validate your solution, but building it for a full production release isn’t one of them. Prototyping is not a linear process from low-fi to high-fi. The method needs to fit the assumptions being tested and the type of solution being built. If you’re in an enterprise setting this might mean a live data prototype which means developer time with high fidelity designs. This can still be done quickly and is a great way of building a broader community of supporters, champions, and allies.
• Scale. At the beginning you’re not trying to answer ‘ will this scale’ because you don’t know if you’ve found the right solution, but you need to do what you can to identify scale risks so you can engage the necessary stakeholders as you’re moving along the project. Having these conversations early and in a low-stakes way can avoid a morale-crushing halt signal just as you’re getting ready to release or grow bigger.

Fortunately, there are some tools that we can borrow from the start-up world (with a few tweaks) that help us work through these areas and communicate clearly throughout.

Faster learning with a canvas

What’s brilliant about the Lean Canvas (introduced by Ash Maurya) and the original Business Model Canvas (introduced by Alexander Osterwalder) is that they both force product teams to consider the system in which a product operates. Rather than identifying requirements, setting a sometimes artificial deadline, building, and then pushing it out to users, each piece of the Canvas is considered an unknown — something to test and experiment with.

This process of testing the different pieces of the canvas is illustrated well in the graphic below from Ash Mauyra’s Running Lean:

From Ash Maurya Running Lean

But if you’ve looked at just about any Canvas in the links above, you’ll notice an important gap for public orgs: they all assume that you’re operating in a consumer market and that you can clearly measure your revenue and costs.

For most social enterprise and government agencies, the value stream and ‘marketing’ channels look quite different. Bridging this gap is critical to help product teams within those agencies apply the same principles without falling into the ‘We’re different so…’ trap of skipping over answering similar, if not the same questions.

You likely know what this looks like when it doesn’t happen:

• A new tool or dashboard is developed, but the people who are supposed to benefit from it don’t know why or how they should use it;
• A team develops a new report but later finds out that someone else already created something similar that is already part of a different work-stream;
• A team develops a new solution but later learns that the data they’re including has different business rules, milestones, or benchmarks than what their users need in their day-to-day.

Mind the Gap(s)

While you might still find yourself in one of these situations, there are some concrete steps you can take to limit your exposure to them.

1. Create a document that forces you to identify your assumptions. Whether you want to use a canvas, a google doc, or something else matters less than whether you have a process for working through each set of questions. This is also the place to identify external commitments that will constrain you and the team. The earlier people know this, the more time you can focus your creative energies on the unknowns and the more trust you’ll build from your team.
2. Run a pre-mortem with your first hypothesis. Assume the worst — what would happen if you lost access to your users or you weren’t able to market your tool the way you had originally planned. Use this to develop plan B and C (and D and E?) for how you’ll develop a feedback loop and get the word out to users.
3. Prioritize building a small community of both users and support staff. If you’re in a government org, you probably don’t have either an equivalent of a sales or customer success team. Especially at the early stage of a product, you can create a lot of the same value from those teams by working on developing relationships with both first-mover users and staff that are ‘field’ facing who can be your advocates, allies, and thought partners. Cagan calls this out as the most important thing PMs can do to win over other parts of the organization.

In short, you need to re-imagine the parts of the canvas that don’t work for you not by excluding them, but by getting creative about how to build communication and support channels. The first part of that process is identifying the problem to solve.

Discover fast. Learn out loud.

There are many different to both identify a problem and test some of ideas, but if your immediate inclination is to rally a product team to build something, you’ve missed so many important steps. To sum up, ways you can keep yourself, your team, and your stakeholders in check are:

• Align around a story and vision,
• Pursue the problem with the people who are experiencing it,
• Build a durable community of people invested in solving the problem,
• Run experiments that help you uncover the magnitude of the problem and potential for a solution,
• Share what you’re learning frequently and openly. Be humble but brave.

There is no magic formula for stating that you’ve validated your assumption and found product/solution fit. The simple truth is that users behave differently outside of an experimental setting. The best you can do is be explicit about what you’re testing, gain alignment internally on how you’re going to test it, and share back what you learn with humility, openness, and discipline.

(The usual disclaimer: the thoughts and opinions expressed here do not represent the perspectives of the NYCDOE.)