Editor’s note: Joe Procopio is the Chief Product Officer at Get Spiffy and the founder of teachingstartup.com. Joe has a long entrepreneurial history in the Triangle that includes Automated Insights, ExitEvent, and Intrepid Media. He writes an exclusive  column about startups and entrepreneurs which is published on Mondays. It’s part of our Startup Monday package.


RESEARCH TRIANGLE PARK – Why are some of the simplest products successful while more complex products never find traction?

It’s actually kinda easy to build products your customers will love, you just have to let your customers build your products for you. Simple enough, right?

But while every expert will tell you to listen to your customers and build what they want, none of those experts stick around for when you’ve done exactly that and those same customers aren’t buying what you’ve built for them.

Joe Procopio (Photo courtesy of Joe Procopio)

In 20 years of growing product-based startups, it took me a while to learn that when you’re building your product, a sharp knife is good, a Swiss Army knife is bad. Your customers will tell you, loudly and often, that they want the Swiss Army knife, and the more tools on it the better.

That’s going to lead to failure. Here’s how to establish a customer-driven build process without drowning your company in complexity.

Why the customer is (almost) always right

When I first started out as an entrepreneur, I had the young-person’s mindset aligned with that Henry Ford quote: “If I had asked my customers what they wanted, they would have said faster horses.” I built products and companies that I imagined into existence, regardless of their viability in whatever market I was choosing to ignore.

It took two failed self-founded startups, not to mention several aborted attempts at founding those two startups, to realize that I could build the best damn product in the history of mankind, in my own mind, and watch it all collapse again. Or I could start listening.

That’s when I became a disciple of the problem/solution method of entrepreneurism. This method of developing both company and product is based on building from the market opportunity in, rather than from the product feature set out.

But listening to the customer doesn’t escape Ford’s gravity. Customers just want their problem solved, they don’t care about solving every variation of the problem for every variation of themselves. Thus, they will patch, they will workaround, they will rig — they will invent all manner of shortcuts to create their own personal faster horse.

So when it comes to a customer-driven building process, remember that the customer is (almost) always right. The entrepreneur just has to turn horses into horsepower.

Always ask, always listen

I asked the subscribers to my Teaching Startup newsletter — a few hundred working entrepreneurs — how often they reached out to talk their customers about their experience?

  • 42% said Daily.
  • 32% said Weekly.
  • 16% said Monthly.
  • 10% said Quarterly.

I also listed “annually” and “never” as options but nobody chose those.

Even if you take those numbers with a grain of salt, three-quarters of the entrepreneurs in that sample talk to their customers at least once a week. And to me, that feels right.

Always be asking. Even if you run the kind of business where one-to-one communication isn’t always possible or necessary, it never hurts to sneak a survey into just about any digital communication that your customers initiate, as long as it’s on point. In other words, if it’s a support request, the survey should be about the support experience. If it’s a sales request, the survey should be about the sales process.

But in both of those examples, you can always tack on an ask about the overall product or service experience as well.

Always be listening. Respond to everything and document everything. I’ll get into why with the next two guidelines.

Always respond and respond positively

Every company, and especially every startup, is going to have at least one person tangentially involved with the business — could be a board member, an investor, a partner, a supplier — who is going to tell you how to run your business.

Often, these people will suggest the impossible, or at least the expensive, or something way down on your priority list, or something you’ve already tried and you know won’t work.

Now imagine that person doesn’t know the first thing about the inner-workings of your business. This person is your customer. In fact, customers with the best of intentions, maybe even your biggest fans, will suggest fixes and new features that are entirely off the wall.

You have to respond and you have to respond positively.

I worked with a guy once who, if anyone made a negative comment about our offering, would fly off the freaking handle. I don’t know how many customers we lost because of this behavior, because it wasn’t just the customer he unloaded on, it was every person that customer talked to.

Just because a customer (or board member or investor or partner) suggests something, doesn’t mean you should do it. And just because you’re not going to do something doesn’t mean it’s a stupid idea.

Always build on trends, never on request

A request isn’t a valid request until it’s a pattern. Every customer you encounter is different, and their needs are all different. When you start to see a pattern emerge, that’s when you act.

That’s why it’s important to document every customer request, every support issue that implies a change, and also take notes from every session you have when you talk to your customers about their experience with your offering.

You don’t want to rush right out and build a feature or make a fix the first time a customer requests it. You might not want to build after several requests. But when you get enough requests that it becomes either a cost or an opportunity, it’s time to take the next step.

Always ask the revenue question

At my current startup, three of us on the executive team take every technical, functional, operational, product, and internal request that comes in and prioritizes them weekly over the course of an hour. 

For every request that came in, we ask two simple questions.

For feature requests, it’s “How often is this needed?” and “How much revenue will it generate?” For fixes that aren’t critical, the questions are “How often does this happen?” and “How much does it cost when it happens?”

Then we do some simple math: Frequency times dollars. This doesn’t always dictate the priority, but it sure helps us categorize.

Always roadmap it first

There’s no slower and more painful way to kill a business than by having a dozen or more “top priorities” going on at the same time. You already know that you need a roadmap and you need to stick to it, so when new priorities come in, they need to fit into that roadmap. The roadmap always wins.

When you don’t live by the roadmap, you wind up building two or more products at the same time. Technical debt — or service debt or operational debt — doesn’t just spring up out of nowhere. It happens because too many customers want too many different things and it’s hard to say no.

Just imagine a future where all your customers are happy and your stress level is low. Then take a deep breath, and do the right first thing first.

Always experiment before you commit

Before I launch any product or service, or before I release a new feature, or before I make a major tweak in how I operate my business, I put out a version that’s relatively easy for my customers to understand and use but difficult for me and my company to manage.

I call this the paper MVP. Before I automate, integrate, and track the success of the change, I give the change its best chance at success. This will do a few things for me:

  • It will save me the headache of spending time and money building a robust version of an idea that doesn’t generate the kind of return everyone thought it would.
  • It will surface all the ways the customer will engage with the change that no one was thinking of, and give me a chance to either patch it or build an off ramp before it becomes a critical problem.

Sometimes, I’ll even leak a new feature before I even attempt to build it. And if no one is overjoyed at the arrival of this new feature, I might end up not building it.

This isn’t a bait-and-switch, it’s trying to turn the anecdotal into something factual. It’s reducing risk and avoiding headache. It’s making sure that no matter what your customers tell you they want, you give them what they need.

Because no matter how much of a lifesaver that corkscrew on your Swiss Army knife is when you use it once a year, you might be better off with just a sharper, slimmer blade.


Hey! If you found this post actionable or insightful, please consider signing up for my weekly newsletter at joeprocopio.com so you don’t miss any new posts. It’s short and to the point. Or if you’d like more tactical startup advice direct to your inbox, get a free trial of Teaching Startup.