The 4 Steps We Used to Build Our Category POV at BlockSpaces (Part I)

Reading Time: 6 minutes

In mid-2022, BlockSpaces hired me to help them apply category design thinking as they matured as a startup. Two months after I joined, our team had developed a strong category point-of-view (POV) that’s not only been guiding our marketing but our product roadmap and overall strategy as well. In this post, I’ll explain the exercises we used to craft our POV.

But first, some context.

As I write this, BlockSpaces is an early-stage startup with a couple of seed rounds behind it. We’re about 15 people, mostly engineers, a marketing lead (me), a business development lead, and some operations folks. Broadly speaking we’re in the blockchain/Web3 category.

However, what we’re building is unlike anything else that exists: an integration platform that connects Web2 software (think accounting, ERP, point-of-sale apps) with Web3 protocols (Bitcoin, Ethereum, and so on). This addresses a known problem in the enterprise space – that getting traditional business applications to work with blockchain protocols is generally a pain in the ass.

That should give you enough context for now; I’ll share more details about the problem and solution as we go.

A quick aside: if you are under the assumption that building a POV requires a deep knowledge of an industry, that isn’t true. The job of someone leading a category design exercise is to pull out insights from the CEO and founding team. Their job is NOT to come up with a POV on their own, or to tell the CEO what it’s supposed to be. I only had a surface-level understanding of blockchain going into this process, and still am a long way from considering myself an expert.

We broke down the category POV development into four exercises:

  1. Problem exploration and thesis
  2. Future state exploration
  3. From-to development
  4. POV creation

In this four-part series, I’ll walk you through each, and share some artifacts we created along the way. In part one, I’ll explain how we explored our problem and build a thesis around what our category would be solving for.

Problem Exploration

At its core, category design thinking is all about understanding a problem at a deep level. If you can grok 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.

In a problem exploration exercise, all I’m trying to do with a team is to unpack how they see the problem. Ideally, the team’s already spent time in the real world gathering raw intelligence. If not (or if that hasn’t been done in a while), I’d be working on having those conversations before starting on anything below.

When brainstorming on the problem, it’s important to have input from across the company. Because when you’re solving a new / thorny / seemingly-intractable problem, there’s usually quite a bit of nuance and it can take a while to unpack.

In an exercise like this, we went through questions like:

  • What prompted you to found this company?
  • When and how did you discover that there was an unsolved problem?
  • Who is experiencing this problem? Who else?
  • What are the second- and third-order consequences of this problem?
  • Are there past situations we can draw parallels to?

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.

Whiteboard outlining the category problem.
Our initial brainstorming session to map out the problem

Developing a Problem Thesis

Once we gave our team the chance to explore all the nooks and crannies related to our core problem, we needed to refine our thinking. This stage is also pretty messy and requires a few iterations before things start to become clear.

Here’s my first attempt at documenting our team’s thinking:

Problem exploration board
Our first attempt at mapping out our problem left out a few things.

Each of the columns above represents one of the facets to the problem we were trying to address. Here they are, explained:

  1. 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. To even build a blockchain project, a developer needs a special kind of Web3 infrastructure before they can even begin building anything
  3. 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. For a dApp to have business value, it needs to be reusable by industry peers and trading partners

This was a good start, but as I discussed this with our team, we hadn’t quite gotten it right.

Especially with that third point, there was more to it than we initially identified. True, building a dApp is a skill that most enterprise developers lack. But that wasn’t all. Getting a fully-functioning Web3 app to interact with a Web2 application (like NetSuite) was a whole other challenge altogether – a much more difficult one, in fact.

So we revised our problem thesis to reflect this, and added more context to our thinking along the way. For example, we documented the fact both Web3 infrastructure companies and enterprise solution providers (like IBM) failed to deliver a feasible and cost-effective way to use blockchain:

Problem refinement
The next iteration of our problem thesis gave us a stronger handle on the issue, but we weren’t quite there yet.

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

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.

One last thing I want to call out – every yellow box above represents comments that our team made as we went through this discussion together. The goal wasn’t to come up with something perfect; it was to present our current thinking, then mercilessly pick it a part to make it better.

On our third pass, we had an epiphany. Yes, there were multiple barriers that were keeping enterprises from using blockchain. But the “aha” was that we didn’t need to solve all of them. Other players in the Web3 space were already addressing a couple of these issues. It was that third pillar (getting a fully-functioning Web3 app to interact with a Web2 application) where we saw a huge gaping hole. And that’s what we needed to solve for.

Here’s the final iteration of this exercise.

Problem refinement v3
Only in our third iteration did we get enough clarity to move on in the process.

The real outcome of this process was that box at the bottom, which reads…

For these solutions to be adopted easily and used effectively, they need to built in a single, integrated platform. BlockSpaces is building these solutions in a holistic manner that will allow enterprises to deploy blockchain projects with a single platform.

As you’ll see in my next post, we ended up refining this further. But we were close enough that we could move on to the next step: mapping out the solution to this problem. I’ll walk you through that process in my next post.

Until then, make sure you’re subscribed to the newsletter and be sure to check out my complete guide for getting started with category design.

Share this:

Subscribe to Flag & Frontier

Get the newsletter that will help you become a better category designer.​

Book a Category Design & Coffee ☕️

Book a free 30-minute consultation to explore where you need to head next on your category design journey.

Get the Category Design Guide

The Newcomer's Guide to Category Design

Want to get started with category design? Get 44 pages of advice from 30+ practitioners.

About the Author

John Rougeux

John Rougeux has helped multiple companies through the category design process. Connect with him on LinkedIn.

Recent Posts


Get the newsletter that will help you become a better category designer.

About the Author


John Rougeux is VP Marketing Strategy at BombBomb. Connect with John on LinkedIn.

Recent Posts