Product Design Process

Talking to and observing your customers is extremely insightful. Customers will always surprise you with their insights. Just be careful you understand their intent and problem; don't just build simply what they ask for.

Talking to and observing your customers is extremely insightful. Customers will always surprise you with their insights. Just be careful you understand their intent and problem; don't just build simply what they ask for.


All companies handle product management differently. The best are known for being customer-centric and design-driven. While this means different things to different people, I thought I'd illustrate some best practices I've picked up over the years.

I've been lucky to work some of the best in the business and this is what I've learned: 


Step 1: Observe & Talk To Customers

A famous Product Designer you may have heard of didn't use user focus groups or ask customers what they wanted:


"You can't just ask customers what they want and then try to give that to them."

Steve Jobs


I happen to agree with this to some extent. However you do need to find out what problem you're trying to solve. Skillfully conducted user research can help you start in a much better place than just guessing at it.

Having said that, when we do show a prototype or design to a customer, we carefully observe and record them using the product. Often what they say they are doing and what they are doing are not the same.


Are they smiling? Happy? Frustrated? Are they delighted, or confused or ambivalent? Their face tells the story. 

We utilize two kinds of tests:

1. Show customers your product and ask them to describe it in detail
2. Give customers tasks on your product and see if they succeed 

Test type #1 helps us solve the mental model problem. If customers can't clearly describe what they're seeing and what they're supposed to do, you need to start over and simplify.

Test #1 A set of mockups that refreshes a billing and accounting system for an online school. Do they know where to make payments? Where to update their payment methods? What about downloading statements? 



Test #2 Example An interactive prototype where we wanted to see if this customer could figure out how to filter and facet an e-commerce art site. Was she able to notice the color filters? Was she able to know how many types of art were available? 

Developing a hypothesis and strategizing about what you want to design and build first is essential. You also have to know what you're going to measure and what defines success.

Developing a hypothesis and strategizing about what you want to design and build first is essential. You also have to know what you're going to measure and what defines success.


Step 2: Product Strategy

Once you've observed and talked to your customers, you'll come up with a hypothesis, or a set of them. These are typically called product themes, a concept pioneered by Bruce McCarthy. Within your product theme (say "improve conversion"), you'll have concepts you want to design, test, build, deploy.  

This is the goal-orientated and solutions-minded approach, rather than the "build feature X" approach. 

Let's say you had to present a solution to a customer. Which is an easier story to sell?

“You can now use this real-time data dashboard via your content management system enabling you to filter the data and extract reports.”


“You can use our data to decide on whether now is good time to sell your house.” 

Product strategies come in four distinct types: vision, goals, roadmap, and backlog.

Using my work at eNeighbr where I was Head of Product, I'll illustrate: 

1. Our product vision is the 35,000 view problem we're trying to solve:


"Missing package deliveries at home is a hassle. Have your packages delivered to a nearby neighbor who will sign and hold them for you."


2. Our product goals were based on responsive web (although I fought for and lost the native app debate).


1. Allow a customer to send a package to an eNeighbr
2. Register new eNeighbrs
3. Allow customers to pick up packages from eNeighbrs
4. Allow eNeighbrs to release them
5. Pay eNeighbrs
6. Get paid by customers  


3. Our product roadmap was based on the process workflow and product design work that had been done. We laid out themes (which aligned with our goals) and wrote user stories for the developers, who were offsite. We did this with Google Docs, but today we'd use ProductPlan or other SaaS solution. 

4. Our product backlog was a set of user stories in Pivotal Tracker. We asked developers to estimate our user stories once they were all entered, we asked developers to estimate them. We gave product demos and showed them every pixel and interaction. Once they gave us estimates, we then prioritized the user stories and made changes to the designs and workflows to better optimize the build. 

We then QA'd the build and did another round of fixes. When it was solid, we did a beta launch to family and friends to get the last few bugs out. Then we launched live in NYC. 

Check out our commercial, which we shot and edited ourselves, starring the CEO as Santa!


Don't forget to setup your metrics! What are you going to measure and how? What constitutes a good or bad result? Different metrics (and their results) mean different things to different people. Make sure your teams and stakeholders know what goals you'll be measuring and grading.


One final note is don't get bogged down in the strategy step. It's easy to have endless meetings (and "Death by PowerPoint") talking strategy. Any pillar in your strategy can be easily knocked down (or built up) by quickly designing and testing actual product. That's what your customers will use: product, not product strategy.

So get to designing quickly!

Design, test, iterate.

Design, test, iterate.


Step 3: Design & Test

Now the real fun begins. Let's design! This is where product designers earn their keep. Typically we employ a team kick-off meeting to get the troops rallied. Not always, but for more complex problems, yes. 

A Design Studio is a really cool team building and product development process that I've been using for years now. People really love it. While you can read more about Design Studios elsewhere, they are essentially a cross-functional team sketching exercise. Here's a recent one I conducted to help design an ad campaign dashboard:

One of the best things about design studios is how democratic and social they are, and how they show just how hard designing something from nothing can be. 

Did you realize the famous clickwheel on the original iPod did not come Steve Jobs or Jony Ive? No, it came from the marketing guy, Phil Schiller. You just never know when or where innovation will come from. 


Make it beautiful. Beauty is built into our brains and judgement forms not in seconds, but fractions of a second.


People will judge your product in as little as 500 milliseconds (about 1/2 a second). Many researchers were skeptical of this, so they conducted their own studies and found that judgement can occur in as little as 50 milliseconds (1/20th of a second!) I've even seen a study where judgement about design occurs as fast as 17 milliseconds. This is like watching a lightning bolt!

So be sure all the prototypes and product you test and show your customers is as delightful as you can make it. 


There is new research that shows that if a product is "beautiful" but not particularly easy to use, customers will still give it a thumbs up. Who knows how long this trend will continue and if an over-emphasis on "looking good" but not "working well" will reverse these findings.

This is dangerous territory for product managers and product designers. We should always strive to make our products easy to use, and there is no excuse for not also creating something visually appealing.

Based on this research, you should make every effort to. 

Developers! Developers! Developers!

Developers! Developers! Developers!


Step 4: Execute, Deploy, & Measure

Perhaps no more important step is executing on your product vision. You can have the best ideas and designs in the world, if they aren't executed properly, you might as well forget it. 


The best front-end engineers are in high demand for a reason: they're the key to how well your product does. 

Working closely with developers is probably my favorite part of the job. As a former developer myself, I speak enough tech to make them feel comfortable sharing issues with me. We often arrive at solutions that are sometimes even better than the original vision. 


There are always shortcuts you take. But what you focus on getting right is the key differentiator.


More often than not, we engage developers early and often in the product process. They can help you go in directions you never thought possible - or plausible. The best engineers are the ones who think like customers and want to work on making the systems work hard so the customer experience is the best it can be.

Thank you for taking the time to read through some of the best practices I've discovered over the years. 

TL;DR talk to and observe your customers, figure out their problems but be careful not to just give them "features they ask for" - strategize and envision - but design and test quickly, and most of all, execute the best you can by having great developers.