When a business has a novel idea, there’s one challenge that almost inevitably follows: communicating the importance of that idea to potential customers, investors, and employees seems to require a herculean level of effort.

Founders suffer especially from this challenge. They’re so close to the product that they lose sight of the big picture, and they struggle to convey what makes their vision different from “just another technology company.”

That’s why BlockSpaces asked for my help in applying category design.

As an early-stage startup solving some previously-intractable problems in blockchain, the company had invested two years in developing its technology, but despite that work, the narrative behind it remained fuzzy.

In this 4-part series, I’ll share the process we used to transform a hazy vision into to a clear and powerful category point-of-view (POV) that drove interest from early investors, partners, and customers.

If you’re not familiar with this concept, here’s a good primer on what a category POV is.

The 4 Steps I Use to Build a Category POV

Whenever I work with a client on a POV, I break the process into four parts.

1. Problem thesis – defining the boundaries of the problem you’re solving for the consequences for your customers of leaving it unsolved.
2. Future state definition – creating a vision of what your customers’ world should look like once this problem is addressed.
3. “From-to” development – linking the problem and the solution together with specific transformations that your category will deliver.
4. POV creation – turning these ideas into a succinct narrative.

In this first post, I’ll share the steps we used to create our problem thesis.

Developing the Problem Thesis Starts with Brainstorming

At its core, category design thinking is all about understanding a problem at a deep level. If you can understand the problem, it’s much easier to develop a unique point of view about how it needs to be solved. Skipping this step puts you at risk of having nothing relevant to say and/or building a solution no one needs.

Developing the problem thesis begins with mapping out everything a client thinks the problem is. This comes from first-hand experience, customer interviews, competitive intelligence, and research. It’s important to get everything on the table, because knowing what isn’t the problem is just as important as knowing what is.

Here some of the questions we used at BlockSpaces for this exercise:

• When and how did you discover that there was an unsolved problem?
• Who is experiencing this problem directly?
• What are the second- and third-order consequences of this problem?
• Why is this problem unsolved?
• What are customers doing instead?

At this stage, teams will often identify tangential problems or aspects of the problem that they don’t need to solve, and that’s OK. We’re just brainstorming to get a lay of the land.

Going into this exercise with BlockSpaces, we already knew that enterprises had a difficult time getting business value from blockchain. That was the premise upon which the company was founded.

But by going through the process of mapping out all facets of this problem, we discovered that there was more to the story. The challenge didn’t come from a single source, and leaving the problem unsolved had multiple consequences. Clarifying those would be our next job.

At this stage, we’re not trying to simplify our thinking or assign a name anything. We’re just trying to get everything out on paper so we can start to gain some perspective on what we’re actually trying to solve.

Much of the information gathered here will actually be tossed. In a discussion like this, teams will often identify tangential problems or aspects of the problem that aren’t really something we need to solve for, and that’s OK. We’re just brainstorming to get a lay of the land.

When we did this exercise BlockSpaces, we hit upon the issue I outlined above: enterprises have a very difficult time getting blockchain to work with their core business applications. But we found there was more to the story. The challenge didn’t come from a single issue. The problem had multiple facets, and clarifying those would be our next job.

Refining the Problem Thesis

Once we distilled down our thinking from our whiteboard sessions, we initially uncovered four core barriers that kept enterprises from getting business value from blockchain:

1. Context. Enterprise developers need to figure out how to work with blockchain protocols, and they need to understand which protocols are appropriate to their use case.
2. Infrastructure. To even build a blockchain project, a developer needs a special kind of Web3 infrastructure before they can even begin building anything.
3. Technical Expertise. The process of building web3 applications (or dApps, for “distributed” applications) requires its own set of skills and expertise, which most enterprise developers don’t have.
4. Extensibility. For a dApp to have business value, it needs to be reusable by industry peers and trading partners.

Here’s the document that captured this thinking:

This was a good start, but when I presented this to the team, it became clear that we needed to deeper on a few areas.

In particular, the third point needed some work. The problem wasn’t just that businesses didn’t have technical expertise on building blockchain applications themselves; they also faced huge technical hurdles in integrating blockchain with their core business software. To address that, we replaced “Technical Expertise” with “Connectivity” – a higher level problem that spoke to the real issue.

We also uncovered more material on why the current approach to enterprise blockchain (hiring IBM or Amazon failed to deliver a feasible and cost-effective way to use blockchain. Here’s what the next iteration looked like:

This exercise gave us enough confidence to develop an initial summary of our problem, which read:

As long as these four barriers remain, blockchain adoption among enterprises will be slow and of limited business value. Today, existing businesses aren’t focused on addressing this challenge. They are either focused on the needs of the web3 community only (as is the case with BCaaS providers), or they address the problem by providing isolated, siloed, and expensive solutions that cannot be readily extended for use across an industry vertical (as with IBM Blockchain).

We still had some work to do, but you can start to see the problem definition taking shape.

Iterations Lead to Epiphanies

On our third pass, though, we had an epiphany.

We realized that we didn’t need to solve all of these barriers ourselves, because we found other players in the blockchain space that were already working on them. Had the scope of our problem gotten too broad, we might have seen those companies as competitors. But because we shifted our thinking to see them as complements to our solution, they became potential partners.

This is why setting the bounds of your problem is so crucial!

Here’s the final iteration of this exercise.

At this point, we had enough clarity on our problem to move forward with the next phase of the POV development process: defining the future state that our category would deliver for customers. Until then, make sure you’re subscribed to the newsletter and be sure to check out my newcomer’s guide for getting started with category design.