Ever found yourself in a sprint, building at full speed… and quietly wondering why you’re building it in the first place?
Or maybe you’ve kicked off a project with solid research, only to see it unravel as soon as dev handover hits?
Or—classic—you’ve got a beautiful prototype, but no one’s quite sure if it’s solving a real problem?
If any of that sounds familiar, you’re not alone. And you’re not doing it “wrong.” You’re probably just trying to do good work inside a process that wasn’t built for the problem you’re solving.
But before we talk process, we need to talk product alignment.
The Sweet Spot: What Are We Actually Building and Why?
Before you reach for a process, a framework, or another design sprint template… take a beat. Ask the team: Are we aligned on what this product is meant to do?
That sounds basic. It rarely is.
A lot of wasted effort (and tension) comes from teams working at full speed without shared clarity on:
- Who this product is for
- What problem it’s solving
- How it connects to the bigger picture
- Whether it’s even possible to build well
This is where the Sweet Spot comes in—the intersection of:
- User Needs – Do people want this? Will it fit their lives?
- Business Goals – Does this move the needle for the company?
- Technical Feasibility – Can we build it without duct tape and tears?
If your product idea only lives in one or two of those spaces, the project’s already off-balance. And misalignment here isn’t just a strategy problem—it becomes a process problem too. You end up researching the wrong things, validating the wrong assumptions, and solving the wrong problems really efficiently.
So before you optimise anything, pause and check for alignment:
- Is this desirable?
- Is this viable?
- Is this feasible?
If the answer isn’t a confident “yes” to all three, your process doesn’t need streamlining—it needs reframing.
Designing from the Sweet Spot, Not towards It
Once you’re truly aligned, it becomes less about selecting the right framework and more about choosing the right approach for this moment, this team, and this risk level.
I’ve worked across agencies, enterprises, startups, and glorified chaos factories. Here’s what I’ve found useful:
Design Thinking: When You’re Still Figuring Out the Problem
Design Thinking gets misunderstood.
Some teams see it as overkill. Something that slows them down when they want to ship. Others have sat through one too many “what if we reimagined the toothbrush?” workshops and come away thinking it’s just Post-its and vibes.
But when grounded in real product context, Design Thinking is one of the best ways to explore. It gives teams space to step back, question the brief, and uncover what’s actually worth solving.
It’s especially useful when:
- The problem is complex or undefined
- You’re entering unfamiliar territory (R&D, innovation, new markets)
- There’s a high risk of over-investing in the wrong idea
Instead of output-focused milestones, the checkpoints in Design Thinking are learning-focused:
- Have we uncovered real user needs?
- Have we tested different ideas?
- Do we have evidence this is worth building?
It’s especially valuable for validating desirability, the part of the Sweet Spot that’s easiest to ignore and hardest to fake. And if the product doesn’t hit that mark? Better to know now, before you’ve sunk the time and budget.
Design Thinking won’t get your product shipped fast. But it will help you figure out if it’s worth building at all.
I once worked on a high-risk product concept where the team had already locked in timelines before validating if anyone even needed what we were building. We paused, ran a few Design Thinking loops, and cut half the original ideas—mercifully. The rest got sharper, leaner, and infinitely more useful before a single line of code was written.
Lean UX: When You Need to Learn Quickly Without Slowing Down Delivery
Lean UX is often misunderstood as “design lite.” In reality, it’s not about skipping research—it’s about integrating learning while delivering.
It’s built for teams working in fast-moving environments, where speed is essential, but guessing is expensive.
Think:
- Startups and early-stage products
- Projects with tight deadlines or limited resourcing
- Environments where requirements shift weekly (or hourly)
Instead of separating discovery and delivery, Lean UX blends them. You don’t wait for a perfectly polished concept. You test the rough version. You learn in real time. You adapt before it’s too late.
It’s especially useful for validating viability:
- Are we solving the right problem in a way that meets user and business needs?
- Can we iterate quickly based on feedback without blowing up timelines?
- Are we building a product that will work, not just exist?
Lean UX isn’t about rushing. It’s about de-risking ideas without over-investing in them. You design just enough to learn what you need to move forward. No pixel-perfect polish. No three-week concept decks. Just fast, focused, intentional iteration.
The teams that do it well aren’t cutting corners. They’re cutting waste.
In one agency setup, we replaced the classic six-month project plan with a leaner two-month release. Clients got to see and use something real, fast—and we stuck around to refine it in-market, instead of disappearing after a launch party. The work got better. So did the relationship.
Agile UX: When the Product’s in Motion and You’re Refining as You Go
Agile UX isn’t about reinventing the wheel. It’s about making the wheel smoother, faster, and slightly less squeaky—without stopping the car.
It’s the approach that fits best when:
- The product’s already live or close to launch
- You’re working in parallel with engineers, sprint by sprint
- You’re iterating based on actual user feedback, not assumptions
Here’s the key mindset shift:
You’re not trying to release the best product. You’re trying to keep releasing a better one.
Unlike Design Thinking (where you’re exploring) or Lean UX (where you’re validating), Agile UX is about refining. You’ve already got something built, you’re making it better, smarter, easier to use, or more aligned with real-world usage.
It’s especially good for improving feasibility and usability over time:
- Are users actually using the thing we built?
- Are we able to evolve it without breaking it?
- Are we learning and iterating while delivering?
Agile UX works best when designers are embedded with devs, responding to change, and solving problems in tight cycles. It’s less about workshops, more about pairing, standups, and quick validation loops.
Done well, it turns design from a pre-launch activity into an ongoing layer of quality control. Done poorly? It turns into design feedback being delivered 20 minutes before release.
On a large product team, we embedded designers directly into sprints. It meant feedback wasn’t delayed until “after dev”—it shaped what shipped, in real time. Features evolved based on actual usage, not assumption. It also did wonders for morale—there’s something powerful about seeing your work make a difference while it’s still warm.
Frameworks aren’t religion
Here’s the thing: good products don’t come from picking the perfect process. They come from asking better questions—and creating just enough structure for a team to answer them with clarity, not chaos.
So don’t treat frameworks like sacred scripts. Use them like tools.
Start fuzzy? Use Design Thinking to surface what matters.
Need to move and learn? Lean UX keeps you honest.
Already shipping? Agile UX helps you improve what’s already out there.
And if it still feels unclear?
Go back to the Sweet Spot.
Because if it’s not desirable, viable, and feasible, no process will save it.
You’ll just end up building the wrong thing… really efficiently.