Building Context

Before you can map out an Entity Relationship Blueprint (ERB), you first need to lay the groundwork for it. After all, you can’t model what you don’t understand. Otherwise, you’ll settle in, fire up the ole’ whiteboard, start listing out entities like “User” or “Subscription”, and before you know it, you’ve mapped yourself right into a dead end. You begin to realize you’re missing something—not an entity, but something bigger: context.

Just like every punchline needs a good joke or every experiment needs a hypothesis, any solution you design should effectively address a problem. For that to happen, you need to understand the full depth and breadth of your problem. That’s what the Context process helps you accomplish.

In this chapter, we’ll cover how to:

Define the real problem you want to solve with your product
Set clear goals for your product
Determine who your target users are and what they need
Research the competitive landscape
Craft a positioning statement that keeps your team aligned

During this initial step, you’ll be asking a lot of questions. You can think of it as product therapy, and this chapter will teach you how to be a product therapist. In order to make better decisions later, you need to learn how to ask better questions now. Before you can determine the entities of your product, map out the infrastructure, or create a user flowchart, you have to sit with the problem, dig into pain points, and understand motivations. Essentially, you need to help your product find its identity. And like any good therapy session, the hard truths come out if you’re willing to ask the right questions and stay curious long enough to hear the answers.

So take your time. Don’t rush to build something just because you can. Use this chapter to slow down, zoom out, and develop a clear-eyed view of the opportunity ahead. You’re not just validating a product—you’re laying the foundation for everything that comes next.

Getting Ready

The context process is a fact-finding mission. And like any good expedition, you don’t want to set out without the right supplies or the right people. You’re heading into uncharted territory—not just to gather requirements, but to understand the landscape of the problem you’re solving. Before you get started, you need a few things: a solid crew, a clear head, and somewhere to stash all the gold you dig up along the way.

Your Fellow Explorers

If you are the subject matter expert (SME) for this project, you may be able to complete most if not all of this process on your own—but where’s the fun in that? And if you aren’t the SME, you’ll definitely need to invite others to be a part of this process. A good content finding group should include:

The founder, who has the vision for where they want the product to go
SMEs, who will have domain knowledge of the product being built
Customer-facing roles like sales, support, or account managers, who hear real user problems daily and see pain points in the real-world
If possible, actual users, who may be able to reveal blind spots you haven’t considered

An Open Mind

Don’t get ahead of yourself by fixating on cool features, databases, or how you want the application to look and feel. For now, you just need to keep yourself open to where the information you learn takes you. Focus on the problem, not the fix. Focus on your user, not on the buyer you want to acquire your solution in a few years. Focus on gathering context, not thinking of feature sets.

Treasure Maps, Not Sticky Notes

Your expedition will yield a mess of insights, and if you don’t capture them somewhere structured, you’ll forget half of what you learned when it comes time to build.

Set up a simple, centralized place to collect and organize what you find:

A Figma board with sticky notes and clusters
A Google or Notion Doc where you dump interview notes
A spreadsheet that tracks pain points, tools, and personas

Whatever you choose to use, make sure it is easy to update and share with your team. You’ll refer back to this throughout the entire Blueprint process.

The Process

This first phase of the Blueprint Agile process is purely information gathering, so you don’t yet need to know how to map out entities or design workflows in your future app. You just need to be able to ask good questions—which may be harder than you think. I’ve divided up the context process into five simple parts, each one building on the last, so by the time you finish, you’ll have a full picture of what you’re doing, who it’s for, and why it matters.

Here’s how it breaks down:

Step 1: Define the Problem

What real-world issue are you trying to solve? If you imagine the product you’re building as a ship, the answers you identify in this step will be your anchor. Get it wrong, and everything else will drift.

Step 2: Set Product Goals

Once the problem is clear, your next step will be to define what success looks like. At this point, your goals should be focused on outcomes, not features.

Step 3: Understand the User

Once you’ve given some thought to the problem you want to solve and how you want to do it, you need to dig into who experiences the problem and who will need to solve it. Who’s experiencing this problem? What do they do, what slows them down, and what do they want instead?

Step 4: Analyze the Competition

Your users are already out in the world trying to solve this problem for themselves. Whether it’s a similar application or duct tape and spreadsheets, you need to know what they’re using so you can do it better.

Step 5: Write a Positioning Statement

Once you’ve collected all of the pieces, the final step is to bring it all together in a concise positioning statement. This statement ensures you and your team remain aligned as you move into future phases of Blueprint Agile.

Step 1: Define the Problem

Every product needs a purpose, a clear reason for its existence. And no, unfortunately, “to make money” is not a good enough reason. If your product isn’t solving a real, painful, user-facing problem, it’s just a nice idea—and no one pays for nice ideas. They pay for solutions.

To determine what your solution is, you must first understand the problem. That means digging beneath the surface of what your users say they want, and identifying the pain that’s actually driving their behavior.

1.1. What specific problem is your product solving for users?

What’s the actual pain your users are experiencing? Don’t try to pose a hypothetical problem; it will feel hollow and unconceptualized compared to a problem based on a real scenario. A good problem statement is concrete and observable. If you can’t back up your problem with use cases from real users, then it’s probably not ready for a whole application.

To craft a good problem statement, make sure it checks these boxes:

User-centered: The problem needs to be framed from the perspective of the person experiencing it—not “we,” not stakeholders.
Clear and specific: The problem is stated plainly and precisely.
Validatable: A real user would read it and say, “Yes, that’s me.”
Painful enough to matter: The problem impacts time, money, effort, or credibility.
Solution-agnostic: It doesn’t imply a feature or fix.

Let’s look at a few examples to see how this plays out:

Statement	Verdict	Reason
“We don’t have a good way to view project metrics.”	Bad	Avoid framing the problem as “we.” This doesn’t identify a specific user or their pain.
“Project managers have to piece together KPIs manually from four different tools.”	Good	It clearly identifies the user, the pain, and the context.
“Managers need a dashboard that shows real-time analytics.”	Bad	This is a solution, not a problem. It skips the pain entirely.
“Managers are making decisions based on outdated reports that don’t reflect current operations.”	Good	This frames a real-world, verifiable pain point from the user’s perspective.
“Our software doesn’t integrate well with other tools.”	Bad	This focuses on the product’s limitations, not the user’s pain. It’s also vague—what tools? Why does it matter?
“Support agents waste time copying customer data between systems because the CRM and help desk don’t sync.”	Good	There’s a specific user, specific pain, and a clear operational consequence. This feels like a real-world problem.

As you can see, strong problem statements zoom in on real people doing real work and the friction that gets in their way. That is the kind of scenario you want to build a solution around.

1.2. Why is this problem important or urgent to address?

A good product doesn’t just eliminate friction; it eliminates friction that’s actively holding people back, costing them time or money, or causing stress. In other words, a good product should be something users truly, urgently need.

When considering your problem, ask yourself:

What’s the consequence of doing nothing?
What does this problem cost the user (time, money, energy, reputation)?
Is this pain happening occasionally or constantly?
Is it annoying… or does it have the potential to cause significant harm?

Urgency is important for you to factor in because the more significant the cost of the problem, the more likely users are to pay for a solution and adopt it quickly. If the need is not large enough that a user is willing to fork over their hard-earned money for it, then you won’t have a successful product in the end. Mild inconvenience is just not a good enough selling point.

Let’s do a deeper dissection of what urgency looks like.

Problem	Does it Matter?
“Sales reps have to manually create invoices after every deal.”	This could be an urgent problem, because it eats into time they could be spending closing the next sale and directly impacting revenue.
“Operations managers don’t trust the current data in their reports.”	This issue can cause managers to make bad decisions or delay action entirely, which causes cascading inefficiencies, so it would likely be an urgent issue.
“Team members don’t always remember to ‘like’ internal updates.”	Because this is more of a culture or engagement preference, rather than a workflow issue, it’s unlikely to impact the bottom line in some way, so it’s likely not an issue that would prompt investment in a solution.
“The interface feels old and outdated.”	Unless it’s actively causing confusion or abandonment, an old-looking UI is not the same as a broken workflow and won’t be seen as an urgent problem.

If you feel your problem is urgent and needs a solution, then it’s time for the next question.

1.3. How are users currently handling the problem?

If you’re targeting a real-world problem, then the users who experience it have likely already developed some means of dealing with it in order to continue on with their lives. Their “solution” might be clunky, inefficient, or fragile, but it exists, and you need to make sure the solution you’re building will be better than the status quo.

If you don’t understand the current state, you risk designing a solution that:

Solves the wrong part of the problem,
Doesn’t account for ingrained user habits, or
Isn’t significantly better than what they’re already doing.

So, when you’re researching how users are currently handling the problem, what should you look for specifically?

User Expectations: What do users consider “normal” or baseline? Take note of the processes they’re used to working with and the behaviors they’ve adapted.
User Priorities: Which parts of the process frustrate users the most? Look closely at the workarounds they’re trying to improve and the places they’ve invested the most time and energy to make better.
Opportunity Gaps: What’s broken, slow, or manual in their current process? If the users are turning to multiple tools to complete a task, or if the current process is prone to mistakes or delays, these are places your solution could be most effective.

1.4. What frustration or limitation do users regularly encounter?

Users may have cobbled together a workflow or found a few tools that get the job done, but just because something works doesn’t mean it works well. Even the most clever workarounds come with limitations, inefficiencies, and annoyances.

Understanding what users find the most frustrating about the current state is key to identifying where your product can deliver real value. You’re looking for the friction that users have accepted as “just the way it is.”

There are some common types of limitations a custom solution could be uniquely positioned to address:

When manual steps have to be repeated constantly
When tasks take up too much time
When workflows are complicated and lead to delays and mistakes
When current tools are missing critical features
When current systems don’t integrate with each other
When there’s a lack of visibility or insight into data that impacts decision-making

1.5 What would happen if this problem remains unsolved?

You’ve identified the problem, confirmed it’s real, determined that it’s urgent, examined the status quo, and uncovered the limitations users face today. Now it’s time to ask: what happens if you don’t build this product?

Nothing happens.

The problem continues, but users tolerate it. There’s no strong demand, and life goes on. (This might mean the problem isn’t worth solving.)

Someone else builds it first.

A competitor sees the same opportunity and moves faster. You lose first-mover advantage or market position.

The problem gets worse.

As teams grow, customers scale, or processes become more complex, the pain increases, making the eventual solution harder (or more expensive) to implement later.

You miss a window of opportunity.

Industry conditions, buyer behavior, or internal momentum shift. What felt viable now may not be six months from now.

Now, are you psychic? Probably not. But this is the part of the process where you need to make an informed prediction—not based on a gut feeling, but based on everything you’ve learned so far. This is where you start to extrapolate. If the problem continues unchecked, what’s likely to happen? You won’t have hard data for every scenario, and that’s okay. The goal here is to use informed judgment to forecast impact, not wait for irrefutable proof while the opportunity slips by.

Step 2: Clarify the Product’s Strategic Purpose

Once you’ve wrapped your head around the problem at hand, it’s time to switch your focus onto how to solve it. Think of yourself as a doctor—you’ve ran tests and diagnosed the problem, and now you need to determine a treatment plan.

You’re not listing features (yet). You’re identifying the outcomes your product needs to deliver to be considered a success, both for users and for you. After all, this is a business venture. What will change if this product works the way it’s supposed to? What measurable improvement will it create?

This step is all about finding your north star, that strategic purpose that will guide your future decisions, help you shape priorities, and keep everyone aligned when scope creep comes knocking.

2.1. What outcomes or improvements should users experience using your product?

If your product does its job, what changes? That’s the question you’re answering here; not what features you’ll build, but what impact those features will have. Just think of your favorite apps that you use every day—solutions such as Slack, Stripe, Airtable, Notion, Calendly. They disrupted the status quo by removing pain, altering user behaviors, and creating new possibilities. For users, their value is easy to identify. They save time, or improve accuracy, or increase visibility, or speed up decision making—things users care about and are willing to pay for. Defining outcomes gives your product a measurable finish line.

What does this look like in practice? Think in terms of observable improvement. Ask yourself these questions:

What should users be able to do faster, better, or more easily?
What friction will disappear?
What behavior will change?
What measurable improvement will prove this thing is working?

Let’s say you want to develop a time tracking app for freelancers. What are some measurable outcomes you want your users to have?

What should users be able to do faster, better, or more easily? They should be able to track billable hours accurately, attach them to specific projects or clients, and invoice for their time with minimal effort.
What friction will disappear? Users will no longer have to manually enter hours, risk forgetting hours, or switch between multiple apps to track time and generate invoices.
What behavior will change? Freelancers will be able to easily track time in real-time and generate invoices directly from these logged hours, reducing missed billables and admin time spent putting together invoices.
What measurable improvement will prove this thing is working? Users will invoice 100% of billable hours, and time spent on invoicing drops from 1 hour per week to under 10 minutes.

2.2. What metrics or success criteria will indicate the product is effective?

You can’t improve what you don’t measure, and you can’t claim your product is working if you don’t know what “working” looks like. Before you build anything, you need to define what success looks like. That way, when you eventually ship, you’re not relying on vibes, anecdotes, or wishful thinking. You’ll know if your product is delivering—or not—results.

Having agreed on metrics or success criteria at this stage of product discovery is smart for a handful of reasons. First, it keeps everyone aligned on what the product is supposed to do and how to recognize when it’s doing it. Success criteria will also help you prioritize features down the road. If a new feature doesn’t support your success metrics, it probably doesn’t belong in the MVP. Once your product launches, you’ll be able to use these metrics to determine when its time to pivot, as well.

Regarding the metrics themselves, what should you be tracking? Well, that depends on the problem your product is trying to solve and the real-world impact you want it to have.

If it’s a product management app for instance, tracking time saved will be useful.
If it’s a customer support tool, tracking issue resolutions will be useful.
If it’s an HR software, tracking engagement and task completion will be useful.
If it’s an inventory management tool, tracking carrying costs will be useful.
If it’s a sales platform, tracking revenue growth or conversions over time will be useful.

As you can see, there’s no one-size-fits-all success criteria. However, that doesn’t mean all metrics are created equal. Make sure you’re not confusing surface-level, vanity metrics with real signals of product success. Vanity metrics are data points that may look impressive at first glance, but they don’t actually indicate whether or not your product is delivering the value you wanted it to. Metrics you’ll want to avoid including in your success criteria include:

Sign-ups: Everyone would love to get a high number of sign-ups right after the product launches, but don’t plan to use this as a benchmark of success. If those users never return to the platform after the first time, then your product may not be solving their problem effectively.
Time spent in app: This feels like it should be an indicator that your product is gaining traction among your userbase, but more time isn’t always good. They could just be confused or unable to quickly finish their task.
Social shares or downloads: Buzz won’t mean your app is making an impact. Don’t assume that just because someone shared or downloaded your product that it’s because they got value from it.

We get it. Vanity metrics are seductive, but relying on them to determine what success looks like will ultimately be short-sighted and prevent you from understanding how well you’re solving your defined problem.

2.3. Are the product’s goals primarily productivity-focused, decision-making focused, or something else?

Not all products aim to do the same thing. Some make people work faster. Some make them smarter. Some help them stay compliant, aligned, or even just less annoyed. You need to be honest about what kind of value your product delivers, because that will influence everything: your feature set, your UX decisions, even the way you decide to market it to your target audience.

Is It Productivity-Focused?

These products aim to help users get more done in less time or with less effort. This is the most common type of SaaS product, especially in operations-heavy environments. Productivity-focused solutions include apps like:

Quickbooks
Notion
Zapier
Calendly

Is It Decision-Making-Focused?

These products exist to help users make better, faster, more informed decisions. It’s not about doing more, it’s about choosing wisely. Real-world examples include:

Tableau
Google Analytics
HubSpot
Expensify

Is It…Something Else?

Product-focused and decision-making-focused apps are the most common, but not every product is about speed or insight. Some improve visibility, ensure compliance, reduce risk, or simply align people around a shared process. Some examples of software that doesn’t it into either of the above categories include:

Okta
Duo Security
Slack
Vanta

There’s no “right” category—in fact, many products overlap. But picking a primary focus helps sharpen your product’s value proposition and avoids the trap of trying to be everything to everyone.

Step 3: Understand the User

In case you were under any illusions: you’re not building a product for everyone. You’re building it for someone specific. The sooner you understand who that person is, the easier it becomes to design something they’ll actually use—not just something that looks good in a demo.

This is the point in the context process where you start thinking of the human element—who you’re solving the problem for, what they care about, and how they operate day to day. This is also where you might realize you’ve been solving the right problem… for the wrong person. Or you might confirm you’re exactly on track. Either way, you’re grounding your product in real use, not hypothetical utility.

3.1 Who are the primary users?

Just because someone interacts with your product doesn’t mean they’re the person you should be designing for. In every product, there are primary users (the ones feeling the pain and using the solution regularly), and secondary users (these might be managers, reviewers, admins, or occasional participants).

In order to design a successful product, you need to determine who your core user is. These will be the people who drive adoption, determine satisfaction, and ultimately define whether your product is solving the problem well.

What makes someone a primary user? These users will:

Directly experience the problem you’re solving
Use your product frequently (daily or weekly)
Depend on your product for something critical
Would notice immediately if your product broke

One of the biggest traps in product discovery is focusing on the buyer (the person who signs the contract) instead of the user (the person who actually uses the thing). In some cases, the buyer and the user may be one and the same, but there are many instances where they aren’t. In those cases, they may have different goals, different priorities, and sometimes completely different definitions of success.

If you create a product for the buyer and not the user, you may end up with “shelfware”, an app a company loved in the sales call, but that their employees never use. On the other hand, if you design only for the end user and ignore the buyer, you’ll run into issues trying to sell your product. After all, buyers have their own set of goals in mind, and if they don’t like what they see—regardless of how positive user reaction is—they won’t hand over their credit cards.

3.2. What are the manual tasks each user type performs regularly?

Once you’ve identified your core user, you need to zoom in on how they spend their time. What are the repetitive, manual tasks they do day in and day out? What little inefficiencies have they come to accept as “just the way it is”? Whether your product is for a customer support agent, a solo freelancer, a parent managing their household budget, or a college student organizing class notes, these tasks often reveal the real pain you’re solving.

Remember, you’re designing for behaviors, not a job title or specific role. While it’s not wrong to think of your user as a “student” or an “HR manager”, don’t let it distract you from focusing on their lived experiences. For each type of user you intend to have on your platform, consider:

The repetitive tasks that up more of their time than they should
The workaround they’ve found
The processes they do that rely on memory and tribal knowledge to complete
The tedious tasks users would love to skip

The Power of User Interviews

One of the best ways to surface these manual tasks is through simple, open-ended interviews. Don’t overthink it—you just need curiosity and a willingness to shut up and listen.

Here are a few questions to get started:

Walk me through your day. Where does most of your time go?
What do you find yourself doing over and over?
What’s something you always forget, or that slows you down?
What do you wish took half the time it currently takes?

3.3. What pain points or frustrations do these users currently face?

While you’re conducting user interviews, be sure to discuss what irritates them the most. Just because they’re doing something manually doesn’t always make it a problem—doing it manually and hating it is, though. To build a product people actually want, you need to identify what parts of the workflow are causing stress, friction, or failure. These are the things that slow users down, wear them out, or make them throw up their hands and say, “There’s got to be a better way!”

As I mentioned in Step 1, pain is the catalyst for urgency. If you aren’t solving the parts of their workflows that truly frustrate them, they have no reason to switch from whatever solution they’re surviving on today. So, these frustrations are the moments where you can provide true value to your users. To help uncover pain points in your interviews, try asking:

What’s the most frustrating part of your process?
Where do things usually go wrong?
What’s something you always dread doing?
When was the last time something really broke down?

3.4. What specific goals does each persona want to achieve through using your solution?

At this point, you know who your users are, what they do, and where they’re feeling friction. Now it’s time to flip the lens: what does success look like for them? Each user persona is bringing their own motivations to the table. To them, they’re not just trying to “use a tool”, they’re trying to get something done, solve a problem, or hit an important goal.

If you know what your users want to achieve, you can design toward that outcome. If you don’t, you’re just guessing. Taking note of user goals will also help you better prioritize features later on, better measure success from the user’s perspective, and avoid building for edge cases that none of your user personas are that interested in.

Most users are not actively thinking about their goals when using a tool—that’s your job. So, to hone in on what their goals are, try asking these questions during user interviews:

What’s your ideal outcome when you use a tool like this?
What are you ultimately trying to accomplish?
If this product worked exactly the way you wanted, what would change for you?
What does “done” or “success” look like in your world?

3.5. What expertise or experience level do these users typically have?

You can design the most powerful, elegant solution in the world, but if your users don’t know how to use it—or are unable to physically utilize it—it’s useless. That’s why it’s essential to understand your users’ baseline experience level and capabilities before you start designing anything.

Are they new to this kind of tool, or seasoned pros? Are they younger, older, using it on mobile, or relying on assistive technology? Are they working in a high-focus environment or juggling five things at once? Your goal should be to design something that meets users where they are, not where you assume they’ll be.

Understanding the experience level and access needs of all your user types will shape your product in several important ways:

It helps you choose the right level of onboarding and in-app guidance
It informs better UX/UI decisions that match real user behavior and ability
It prevents you from overwhelming users with jargon, complexity, or technical assumptions
It ensures your product is usable by people with different physical, cognitive, or situational needs

For instance, If you’re building a medication tracker for older adults, don’t bury features behind cryptic icons or overwhelm them with too much data. If you’re designing a freelance invoicing app, however, you can assume these users are a bit more technical and will likely be working on a mobile device. To get a better understanding of your users’ experience and capabilities, ask questions like these in your interviews:

How do you usually complete this task today?
What tools or apps do you feel comfortable using regularly?
What frustrates you about learning new systems?
Do you ever have trouble using certain interfaces or features?

Step 4: Analyze the Competition

No product will exist in a vacuum, and that includes yours. Whether your users are relying on other tools, spreadsheets, mental workarounds, duct tape and safety pins, or sheer willpower, they’re already doing something to get the job done. If you have any hope of ever doing it better than their current process, you need to figure out what it is. Analyzing the competition isn’t just about identifying features you should copy. It’s about finding the gaps, inefficiencies, or frustrations that your product can uniquely address. That’s your wedge.

4.1. What tools do your target users currently use?

Start by identifying the actual tools your users turn to — not the ones you think they use, or the ones the industry says are standard. This could include anything from specialized software to spreadsheets, sticky notes, or voice memos. While you should avoid assumptions, you may want to do some preliminary research to identify competitors before asking users about them.

In order to ensure good market fit, it’s important that you have a solid understanding of the landscape your product will need to fit into. Competitor research will help you learn what users are used to see and doing, it will give you insight into what is worth keeping and what should be avoided, and it will help you avoid reinventing the wheel. Your goal here to spot the places you can improve, simplify, or differentiate your product from the current competitors.

When discussing competitors with users, be sure to ask:

What tools do you use to get this task done?
Are you happy with them? Why or why not?
Do you use more than one tool to complete this process?
Is there a tool you used to use but stopped?

4.2. Are there existing tools similar to the product you want to build?

Take a closer look at the products already trying to solve the problem you’re targeting. What are they doing well? Where do they fall short? Your goal isn’t to replicate what they’ve built—while there’s often room in the market for me-too products, copying competitors usually leads to a product that’s forgettable, unfocused, and ultimately unnecessary. Worse, you risk baking in the same mistakes they’ve already made. Instead, treat their work as a map. Analyze it to understand what’s working, what’s not, and what paths they’ve already explored, so you can take a smarter one.

When you conduct your competitor research, you’ll want to go deeper than the marketing site. Landing pages are designed to sell, so while they’re a helpful place to start, they won’t tell the full story. Here are some other ways to learn about your competitors.

Help docs and knowledge bases give you a clearer picture of how the application actually works, including what’s customizable, what’s manual, and how much effort it takes to get started.
User reviews on sites like G2, Capterra, or the App Store reveal common patterns, such as recurring bugs, issues contacting support, or features users particularly love.
YouTube walkthroughs and user-created tutorials show what it’s like to actually use the tool. Watch where people get stuck, how long tasks take, which features go unused, and how they react in real time.
Social media or Reddit threads offer unfiltered opinions. Users tend to be more candid in these spaces, so pay attention to what gets people talking, what frustrates them, and what earns praise.
Trying the product yourself puts you in the mindset of your target user. Go through the core workflow and take notes. What’s intuitive? What’s confusing? What’s missing? Where do you feel friction?

4.3. What do those tools do well? Where do they fall short?

Once you’ve done your research and explored competing tools firsthand, it’s time to break down what they’re doing well and where they’re letting users down. This isn’t about passing judgment. It’s about gaining clarity. You’re evaluating their strengths and weaknesses the same way you would in any strategic landscape. If you want your product to stand out, you need to understand how it’s different and why that difference matters.

Work with your team to make a list of each competitor’s strengths and vulnerabilities. Start a shared doc, whiteboard, or spreadsheet, and list out what you’re seeing for each competitor. Break it into two simple columns: “What they do well” and “Where they fall short”. It’s helpful to do this collaboratively because different team members will notice different things. A designer might catch UX flaws that a developer overlooks, while someone on the business side may spot pricing issues or positioning gaps.

As you go, look for patterns. Are multiple competitors strong in the same area? That might be the baseline you have to match. On the other hand, if they’re all struggling with the same thing, that could be your opportunity to stand out.

4.4. Why would someone switch to your product from an existing solution?

It’s not enough to build an objectively better product; you have to build an attractive product, a solution that is worth going to the trouble of switching to. Most users—whether they’re consumers or professionals—don’t abandon their current tools lightly. Even if the existing solution is clunky, annoying, or outdated, people tend to stick with what they know—and the product that houses their data—unless there’s a clear, compelling reason to change.

This is where many products fail: they assume better is enough, but it’s not. You need to be better in a way that matters to your target users.

What are some reasons users would go to the effort of changing to a new platform?

A drastically simplified workflow
A pricing model that scales more fairly or transparently
A product that’s focused on their use case, not a generic one
Better support, onboarding, or customization

If you still aren’t sure why someone would switch to your product, work with your team to think through these questions:

What pain is so frustrating that users would stop what they’re doing and try something new?
What does your product make easier, faster, cheaper, or more enjoyable?
What’s the “aha” moment your product delivers that competitors don’t?

4.5. What is your key differentiator?

After all the research, interviews, comparisons, and competitive audits, this is the moment to zoom out and ask: What makes your product different and why should that matter to the user?

Your key differentiator is the clearest, most compelling reason someone would choose your product over another. It’s the one thing you want users to remember when they think about what you offer. Not a laundry list of features or a vague promise to “simplify their workflow.” You just need one sharp, ownable edge.

Make sure your differentiator isn’t weak. Saying things like “our product is easier to use” or “we have more features” just doesn’t cut it. First, everyone thinks their product is easy to use. Second, more features usually just means more complexity—users don’t want more, they want better. A strong differentiator is:

User-centered: It’s not just what you think is cool; it’s what your users actually care about.
Tangible: It points to a specific benefit, outcome, or capability.
Unique: It’s something no other tool in the space is doing well or at all.
Memorable: It’s clear, simple, and easy to communicate.

Step 5: Write a Positioning Statement

You’ve done the hard work. You’ve defined the problem, understood your users, studied the competition, and identified what makes your product different. Now it’s time to put all of that into a single, sharp, strategic sentence.

Your positioning statement will serve as your internal compass, guiding how you talk about your product, who it’s for, and why it matters. It’s not marketing copy (yet). It’s a practical, working draft that keeps your team aligned and your product focused.

This single sentence should clearly and succinctly identify:

Who your product is for
What problem it solves
How it solves that problem differently (or better)

For a well-structured sentence, follow this template:

For …
who struggle to …
[product] is a …
Unlike ….
[product] delivers …

Here’s an example of a completed positioning statement:

For print companies who struggle to get customer feedback on time, Ashore App is a proofing platform that automates the review process. Unlike email chains and manual reminders, it keeps orders moving with built-in approvals, deadlines, and nudges.

And another one:

For independent tutors who need a better way to manage their schedules, LessonLoop is a mobile-first booking tool that lets students self-schedule and pay in one place. Unlike generic calendar apps, it’s built specifically for solo educators.

A lot of positioning statements fall flat because they try to do too much at once. Don’t try to cram in every feature or edge case; keep it focused on the core user and core problem. Avoid vague language like “streamline your workflow” or “improve productivity” unless you can immediately explain how. Finally, make sure you’re not centering the company or the product vision instead of the user.

By the end of this chapter, you should have discovered several important things about the product you want to build:

The problem your product needs to solve
What a successful product should look like
Who will benefit the most from your solution
How the problem is currently trying to be solved

Once you’ve completed the context gathering process, you’ll have a clear foundation to build on, ensuring that everyone on your team is aligned and working toward the same north star. With that context firmly in place, you’re ready to move on to the next stage of Blueprint Agile: the Entity Relationship Blueprint (ERB). In Chapter 3, we’ll map out the core entities of your product and define how they fit together, defining a data architecture that supports your goals.