This simple framework has the secret to building what your customers want
How to use it and what to do if you don’t have any customers yet
I don’t think there is anyone in the startup world or the wider business world who will argue with the statement that you should focus on building what your customers want.
But how many people know what that really means and how you should actually go about doing it?
With the rise of Design Thinking and Lean Startup methodologies that now dominate the thinking in startups and big corporations alike, putting users and their problems at the heart of everything you do is a generally accepted concept.
But from my experience, there are a lot of people out there who think this automatically comes from post-it notes, brainstorming, creating user personas and other things that on their own equate to nothing more than innovation theater.
So, what’s the way out of this post-it note purgatory?
Focus on the action, not the planning
First, don’t get me wrong — there are lots of great things to use from the Lean Startup and Design Thinking, but it’s easy to get carried away with their planning tools and shy away from where the action is.
That makes sense because planning (and re-planning, and re-planning again) is much easier than actually getting stuff done. And getting stuff done while involving your customers is especially hard.
That’s where this paper written by marketing professors from the University of Wisconsin comes in. They were looking at things from the perspective of a big corporation, but I think that their ideas translate well to businesses of any size, including startups and solopreneurs.
In their paper, they put forward a framework where they split the act of creating a product into two general parts:
- Selecting — this is deciding and planning what should be built
- Contributing — this is the process of actually building something
(Note: I’ve simplified their concepts down and adapted them slightly, but you can find the originals in the links above)
Then they go down a level to say that these two processes could be done by either customers or the company, so you have a grid that looks like this:
Now that we have this 2 x 2 grid, you have four possible combinations that they named as follows:
- Submitting (Selection by Company, Contribution by Company) — this is essentially the traditional, old-school way that companies would work. Customers are not really involved, you have the company both designing and building products without their input. Then the final product would simply be “submitted” for a customer’s approval or blindly sent out to the marketplace with the hope that they will buy it.
- Collaborating (Selection by Customer, Contribution by Customer) — on the flip side, the exact opposite of submitting is collaborating. This is basically open-source development: you have the community building the roadmap for the product to move forward and the community is also doing all of the development.
- Tinkering (Selection by Company, Contribution by Customer) — Tinkering is where the company controls the final selection of the product, but there are some ways that customers are able to contribute. Here you would have themes or plugins developed by users or in a more abstract sense you could think about platforms with user generated content.
- Co-designing (Selection by Customer, Contribution by Company) — This is where the company is still doing all of the actual work on the product, but the customer is involved in prioritizing and selecting what should be built. A good example of this is companies that have platforms to collect ideas or have public boards for voting on the prioritization of new features.
Here’s the final grid with the 4 categories:
For a startup or anyone trying to build a customer-focused product, be careful of falling into square #1.
And even though you may have done some initial user research and have some user personas, you could still be falling into the trap of just “submitting” your product. It’s easy to go through all of the design thinking methodology one-time, say “job-done” and then just build your product based on that.
The important thing that I took away from this framework, is that this should be an on-going process. And if you think about it hard enough, you can include customers somewhere in your selection or contribution process at all times.
Open-source projects have this built-in by design, so there’s not much to discuss there, but if you are not open-sourced, how can you get more co-designing and tinkering in your process?
Content and community
I’ve given this a lot of thought as I’m currently in the process of building out an MVP for Epilocal, a cloud platform to help local news sites publish and monetize.
There is a bit of a catch-22 when you are just starting out like I am:
You can’t co-design the initial product with customers if you don’t have any customers yet.
And I think this is where people fall into the trap of post-it note purgatory… you can over-analyze and do lots of surveys and feasibility studies and you name it, but a lot of your feedback is just too general and hypothetical at this point.
Until you have target customers that are confirmed via traction and traffic, you are potentially taking yourself in the wrong direction.
For me, content and community are the way out of this trap:
- By leading with content, you can build a community around the general topics that you want to target
- And then once you have a community built up around those topics, you can find ways to involve them in your design process
Take my situation for example: I don’t know yet exactly the biggest technology challenges that people face trying to run a local news site. But I can start experimenting with content around topics that will appeal to potential customers like:
- My Medium publication “On the Local” that is inspired by The Week but uses local newspapers as sources
- Blog posts that appeal to a specific audience like “How to Start a Local News Site: A Step-by-Step Guide”
- Or this post that appeals to a more general audience but will have a wider reach
Then over on the Epilocal website, I’ve set up what I’ve called the “Lab” where I will describe features I’m building and preview them through screenshots, Figma prototypes, short video walk-throughs, demo sites, etc. in order to keep potential users constantly informed about the design process.
I also just launched a community where I will encourage readers of my content to share their challenges, provide feedback on the product features in the lab, or discuss tips, resources and other topics related to local news tech.
This way I’m hoping I can crowd-source some community contributions that may help solve some users’ problems before my product is even ready.
I’ve really found this framework helpful to keep my eyes where the action is.
You don’t want to build your product in a vacuum for too long, but you also don’t want to spend too much time analyzing and end up with nothing more than a bunch of post-it notes and scribbles on a whiteboard.
Focus on building your community and getting your product in-front of that community, either by getting their input on design or getting them to help build it. (or both!)
That’s how you can actually build something your customers want.
Greg Dickens grew up in a small town in rural New York State. After a decade working in finance and technology, he’s now taking everything he learned to create new opportunities for the people he grew up with by building digital tools that help local communities. You can check out his work here.