About a month ago I attended a Product Discovery workshop led by Jeff Patton, who unbeknownst to me is a product/agile/scrum/lean/artistic (to name a few of his talents) guru. My team and I spent an entire week learning to refine our Agile processes, refine how we build a product and feature and more importantly walked away with a handful of tricks and a discovery process that has been life changing. So last week we ran a Discovery Jam (like a code jam but for product discovery) on our own and I can say we will never go back to the old way of doing things.

I can't get into the specifics of the feature we were focused on, however you should still get a good idea of how to replicate the process.

So what does this product discovery process look like? Glad you asked, the process revolves around the following outline:

  • Frame the Problem
  • Empathize with the User
  • Focus on a specific problem
  • Ideate
  • Prototype & Test
  • Plan & Deliver

Frame the Problem

First start out by naming your user, take the first letter of the feature/product you are building and name the user like so: 'Francis the Feature User'. Patton suggested this to make the focussing a bit easier to remember, but we'll get to that in a few.

According to Patton Framing the problem will allow you to understand how solving this problem benefits your user. What are we trying to solve? Who are the players? What are the activities involved?

Make sure you take the time to really understand what it is you are trying to address... Be warned though, your first inclination will be to bypass this entirely because you 'think' you know what the problem is. From my experience you should spend at least a few hours discussing the problem.


Let's set a ground rule: "You Are Not Your User!"

Empathizing is really about immersing your self in the users mindset.

Start by trying to understand how Francis is currently solving this problem, what are the pain points or restrictions? Put yourself in Francis' 4" heels, watch Francis(or your users) complete these tasks, engage and interact with them, ask questions, try to duplicate their process. Is there an easier way currently?

In my case, we were able to look at real word examples provided by our customers, we had setup meetings with a few customers, had them walk us through examples in their current process and talked about potential solutions and had lengthy conversations with internal team members in similar positions about potential solutions and problems.


Next to ideation, this is my favorite part of the process. You've spent hours really understanding the problem and even longer in their shoes. The next step is to write out a Focus statement that will guide you along for the rest of your discovery journey.

A Focus statement is a clear and direct statement focusing on a solution that addresses the framed problem. Everything you do from here on out will need to be compared to this.

Me: "I've come up with this radical and complex solution"

Other Me: "Cool, but does it help Francis solve the problem?"

An example of a Focus statement might look something like this:

HOW can we help Francis the Feature User

TO let the entire world know what he/she is eating for lunch

WHEN we can only talk in 140 characters?


Now comes the fun part... get everyone involved. Close your computers, get the crayons, sharpies and a whole lotta printer paper and draw! This is where you need to time box yourselves, only allow 5 or 10 minutes per round if ideation.

After each round of ideation, tape your pieces of paper on the wall and present your idea to everyone. Allow others to ask questions and get some clarification. You'll begin to see that everyone participating will start converging on a solid solution.

Remember to talk about the framed problem and utilize your focus statement to stay on track. This is really when the magic starts to happen, you'll get inspired by your cohorts and eventually hone in on a really solid idea.

After a few rounds of ideating, cherry pick the best ideas from each other and move on to the next step... building shit!

Prototype & Test

This step can be the most difficult to do effectively... do I sketch, wireframe, Illustrator, Balsamiq, create an clickable prototype or jump right into the code? Honestly, every time you do Product Discovery it should be different. During this workshop I had some high fidelity screens in Illustrator already at my disposal and was able to turn around a few different mockups pretty quickly.

By the second day (early morning) we had 9 screens to show charter customers our progress. By the early afternoon we received some valuable feedback and continued discussing and refining our solution. Throughout the day we shared our progress with various charter customers, internal staff, some of our developers and continued to iterate on our solution based on that feedback.

We spent Tuesday afternoon/evening working through our fifth set of iterations/refinements. I connected my laptop to a television and I went through each screen with my Product Managers, made changes, updated the examples so we could clearly tell a story that made sense and easily explained the solution we had landed on.

On Wednesday morning we scheduled a showcase for internal stakeholders and anyone else who wanted to see our progress. We walked through how we interpreted the design discovery process, the problem we were trying to tackle and the solution we came up with.

What came out of that meeting was valuable discussions around the process, technical considerations/issues, we pinpointed some things we had considered and are already implementing additional iterations based on all the feedback/discussions we were able to have.

Plan & Deliver

This step is just as described, plan out your work and create a backlog of items for your development team to work through. The whole goal of the Product Discovery process is to create a validated backlog of items. This eliminates having to back track to get dev tasks course corrected and the bigger issue of developing the wrong thing. Building a product with your customers instead of at your customers is how you're going to start succeeding more quickly.

As of this writing we're close to 3-4 sprints of development time in order to get our feature incorporated into our product. That's right... THREE days of intense product discovery yielded almost four sprints of work, truly powerful stuff!

Some Take Aways:

Frame & Empathize like a Mutha!

Really take the time to make sure everyone on the team (or in the room) is on the same page. The first two steps are about getting to a shared understanding. It can be a bit difficult for some to see the value of this at first, but once the team has that shared understanding the rest will fall into place nicely.

Time box your tasks.

It's really important to not get stuck on a single task or problem, forcing ourselves to stick with a certain period of time really helped focus on the task at hand and not tumble too far down the rabbit hole.

Iterate Often and Fast!

Not every feature needs to be interactive, there is a time and place for this. We were able to get the idea across using a series of screenshots that I threw together in Illustrator which allowed us to quickly make changes and schedule additional calls with our customers. You can also use sketches or overlays of the actual product, whatever works best for you and your team. Once you have valuable feedback and a solid direction then you can move onto a higher fidelity prototype if necessary.

Adapt this process to fit your needs.

One thing Patton stressed throughout his workshop is this is not an one size fits all solution. There are different ways to interact with your customers, many different ways to ideate, prototype and test. Try to use different methods to see which fits your team the best, it's only going to make the process easier and faster.

Needless to say, we are now drinking the Product Discovery KoolAid! This process has proven to be extremely valuable and highly productive. We have the first go at a validated, well thought out useful solution that resonated really well with our customers and have found a really nice process for keeping Product Discovery, User Interaction, Prototyping and User Research ahead of or Development teams.

Our plan moving forward is to continue these Discovery Jams, refine the process to better meet our needs as a team and continue moving the needle forward! If you have any questions about this post hit me up on Twitter.