As anyone who’s ever tried to build software can tell you, it’s a harrowing process. Most software projects miss their deadlines, exceed budgets, or wind up missing the mark when it comes to what their users want. There are primarily two approaches to building software: Agile and Waterfall. While each has its merits, neither fully solves the problem of creating software in a way that is both predictable and affordable. It’s the classic Goldilocks problem. Agile is too flexible and unpredictable; Waterfall is too rigid and cumbersome. When developing a product, we need something that is just right—a framework that allows us to give accurate time and cost estimates while still allowing us to pivot and course correct.
I started my product consultancy, Brandcave, over ten years ago. As the name might suggest, I did not start out with the intention of designing apps. My background was actually in branding and marketing, but it only took me a few years to discover my true passion was bringing beautiful products to life. It began when I, myself, wanted to build an application to improve creative collaboration on projects. Slow, disorganized proofing workflows are something I have a lot of firsthand experience with as a creative agency owner, and I saw how a centralized proofing platform could vastly improve experiences for both the creative and the client.
To build the product, I met with Ryan Vice and his partner Prashanth Tondapu, who had recently started their software development agency, Vice Software, at Hopdoddy, a local restaurant here in Austin. Over burgers and fries, I told them all about my product idea, called Ashore, and the initial designs I’d mocked up. They bid on my software, and although I passed on the proposal, it wasn’t the last time we’d work together.
Shortly after, Ryan called me on a Friday afternoon with a unique opportunity. He was impressed with my designs and needed a prototype for a web and mobile app for Mike Rowe, the TV personality from Dirty Jobs, and he needed it by Monday. The app would be featured on Rowe’s show, Returning the Favor, to help a deserving organization he was supporting. I designed the prototype over the weekend, and that Monday, Ryan unveiled it on the show. Although I had designed software for other companies in various roles throughout my career, this was the opportunity that changed the trajectory of Brandcave and my life.
Fast forward, I’m a product consultant, helping companies develop strong product strategies that keep projects on time and within budget. Brandcave has worked with organizations like Intel, VMware, the U.S. Department of Defense, Opera, Ellucian, and McGraw-Hill Education to support product initiatives and create paranormal, self-guided user experiences. My career in tech truly began with Ryan Vice, who took a chance on me and shared his knowledge and expertise.
Ryan’s company champions affordability and predictability as pillars of successful software development—values that I carry into every project today. His guidance showed me how these principles can make or break a project, ensuring clients get the most out of their budgets while maintaining steady timelines. Those values are at the heart of Blueprint Agile.
The lessons I learned from building Ashore—and from a decade of selling UX services to help development teams work smarter—taught me a few things. Investing in UX or, more specifically, product prototypes, early will only pay off later. Prototypes help you validate your product faster, which means fewer revisions, cleaner handoffs, and lower development costs. Developers are expensive; clarity is cheap.
I have had a simple mantra when it comes to product management: it takes less time to design than develop, less time to flowchart than design, and less time to model data than flowchart. Today though, we also have AI tools we can utilize. When AI becomes your creative partner, that formula changes. Flowcharts are still useful, but AI prototyping through a process called AI pair programming (or as some might derogatorily call it, vibe coding) lets you skip ahead to working concepts faster than ever before. Blueprint Agile was born out of that evolution: a methodology that organizes product development in a way that balances predictability with adaptability.
The process of Blueprint Agile wasn’t something I sat down and engineered in one go. Instead, it evolved organically through my work with various software development agencies over the years. This methodology has grown and matured over the last decade, balancing the need to provide clients with predictable, affordable services while still maintaining enough flexibility for inevitable changes and pivots.
This book isn’t for the CTO, though they might find it useful, too. It’s written for product owners, founders, and other non-technical leaders who want to build impactful software without losing control of the budget or missing key deadlines. I’ll be focusing on translating business requirements into a structured product strategy. This isn’t about the technical side of development; it’s about shaping your product idea from that sketch on a napkin to a real, viable product.
So, Why Blueprint Agile?
In my own agency setting, you’re often pulled between two worlds: Waterfall and Agile. Many agencies favor Waterfall because it’s understood as the most reliable way to provide clients with clear, predictable estimates. That’s because Waterfall follows a linear path. Each phase has to be completed before the next can begin, and the timelines and deliverables for each phase are typically well-defined or supported through change orders. Clients love it because they know what to expect, but it comes with huge downsides—it’s rigid, slow to adapt, and doesn’t allow for the kind of fast pivots businesses often need, especially in the beginning.
But Waterfall has also been treated like a dirty word in software development for many years. The criticism for it is fair: it’s easy to spend too much time building the wrong thing.
What’s interesting is that AI might change this reputation. Waterfall’s biggest advantage has always been accurate estimation and predictable timelines. With AI, the biggest disadvantage—speed—shrinks. We might be entering a moment where a “lean waterfall” becomes possible: all the benefits of predictability, without the long delays. More on that later.
Agile, on the other hand, takes an iterative approach by breaking work into smaller cycles or “sprints” to continuously deliver new value and allow for flexibility as the product evolves. This adaptability makes Agile great for integrating feedback as early as possible in product development.
Its weakness, however, is the mirror image of Waterfall’s strength. Agile is tough to predict. It can lead to scope creep, missed deadlines, and unexpected costs if you’re not careful. In an agency setting, where clients expect clarity around scope and budget, unpredictability can be your worst enemy.
Blueprint Agile borrows the best parts of both Agile and Waterfall. As a framework of Agile; it retains the iterative, sprint-based structure, but because it has discovery phases that follow a defined sequence, it takes some notes from Waterfall, too. It’s about moving fast and efficiently without sacrificing control or losing focus, enabling you to validate your product idea and arrive at a high-quality outcome in a matter of weeks.
The secret to the success of this process is how I’ve broken the discovery process down into short phases in which I aim for about 80% confidence in each phase, knowing that the next one will build on it and each phase can re-inform the previous phase. By doing this, you avoid the pitfalls of over-planning or spending too long taking a product in the wrong direction.
Where many approaches to product discovery spend too much time overplanning, Blueprint Agile gets you into the iterative process faster, helping you achieve early validation and buy-in without wasting precious time or going over budget. Just like building a house, this process helps you first build a sturdy foundation.
Blueprint Agile can be broken down into five key parts.
- Context: The Context stage helps you and your team clarify the problem you’re solving before writing a single line of code. You’ll define your problem, set clear goals, identify your target users, analyze the competitive landscape, and create a positioning statement that keeps everyone aligned on what you’re building and why.
- Entity Relationship Blueprint (ERB): The ERB helps you map out the core entities of your product and how they relate to each other. It lays the foundation for your data architecture and ensures that your product is structurally sound before design or development begins.
- Information Architecture Blueprint (IAB): The IAB focuses on how information is organized within your product. It outlines how users will navigate through the system and where each piece of data belongs. The IAB helps bridge the gap between the back-end data model and the front-end user experience.
- Proof of Concept (POC): At this stage, you’ll visualize how users interact with your product, either—not both—through a traditional user flowchart or an AI-built proof of concept. A user flowchart is a diagram that maps the key interactions and system responses. An AI-built proof of concept is a quick wireframe of key user experiences that allow you and your team to validate ideas using real, interactive screens.
- Synchronized Delivery: Once your product blueprint is defined, design and development move in tandem through synchronized agile delivery. This stage begins by prioritizing initiatives and then breaking them into coordinated design and development workstreams. By running these tracks in parallel, you accelerate timelines, maintain alignment, and keep the product vision consistent from concept to release.
These phases don’t have to be perfect—they just need to be good enough to move forward.
By the time you reach the final phase, Synchronized Delivery, everyone on your team will have a clear picture of the product vision. Both design and development teams will be aligned around the blueprint you’ve laid out for them, resulting in faster delivery with fewer costly mistakes and the ability to iterate quickly. Instead of going too far down the wrong path, you have the ability to pivot without blowing up the entire project.
That’s why Blueprint Agile works. It’s not about getting everything right from the start—it’s about creating a process that allows you to adjust and evolve as you go.
Who Are You?
Before we dive too deep into Blueprint Agile, let’s talk about you, the non-technical founder. Or maybe you’re a product owner. Or maybe you’re a CTO looking to improve your product lifecycle. Why are we talking about you? Well, the way you approach product development says a lot about how successful your project will ultimately be.
Are You a Cowboy?
When you have an exciting idea, do you immediately jump straight into development, guns blazing? No big plan, just full-speed ahead. Sure, it gets your blood pumping, but it almost never ends well.
Whether it’s intentional or not, cowboy founders tend to trust their developers to do everything: product management, design, development—you name it. Oftentimes, the result is a product that doesn’t quite hit the mark, has a clunky user experience, and probably needs major refactoring down the line.
In my experience, cowboy founders often come to me for help when their project’s already way off track. They recognize that something’s gone wrong, but by then, we’re just trying to triage the situation. These situations are especially difficult because it takes longer to refactor code than it does to create new code. It’s like starting a home renovation project before you’ve looked at the plans. It may look great—or you may have to create some new rooms.
So what is the cowboy founder doing wrong? They opted to use a purely Agile approach, which prioritizes incremental value and delivers new value at the end of every sprint, but creates a more unpredictable environment where scope creep, incomplete work, and mismanagement have an opportunity to thrive.
Or, Are You an Architect?
When architect founders are struck with a new, novel idea, their first instinct is to plan. This founder loves a good plan. They’ll spend tons of time working with designers to create the perfect product, making sure every pixel is in place before development even begins. This sounds great on paper, but there’s a catch: designing in a vacuum often leads to products that look pretty but fail to deliver true value to users.
These non-technical, design-led architect founders tend to underestimate the complexity of the software and handwave through the implementation of difficult features. This is the value that a technical leader would have otherwise inserted into the conversation—the guidance to separate concerns and guide the software into good habits in its architecture.
The lack of insight results in a beautiful, well-thought-out product that’s disconnected from the reality of how it actually needs to function. The designer does their best, but without a solid understanding of the data structure, the product simply can’t reach its full potential. In fact, architects are likely to face the same level of refactoring as cowboys, just in different ways.
What did the architect founder do wrong? They’ve gone full Waterfall. They got so caught up with the need to have a structured, predictable approach that they’ve left little room for flexibility. Problems that could have been identified early on are therefore allowed to linger throughout the design phase only to rear their heads when development begins. Inevitably, the drift between design and development begins as soon as the developers start writing code.
Hopefully, You’re a Blueprint Agile Founder
The Blueprint Agile founder takes a more enlightened approach to product leadership. This is the founder who understands the value of taking things step by step, building confidence at each phase and proving their software thesis at every step. They start by defining the problem, setting goals, and finding team alignment—before creating and validating an ERB and an IAB. Only then do they map out the proof of concept and move into synchronized design and development, all while keeping the big picture in mind.
The Blueprint Agile founder utilizes a centralized, living document—a set of assets that share the vision and direction for the product—which aligns all teams before code or design is produced. They know there will be pivots along the way, and in fact, they even plan for them. What makes them different? They’ve got a clear roadmap, well-defined phases, accurate effort estimates, and timelines that are actually realistic. They’re able to marry Agile’s adaptability with Waterfall’s predictability, setting them up for success.
Truthfully, there’s nothing inherently wrong with being more of a cowboy or an architect. All of these approaches have their time and place, but if you’re looking to build a product that will be able to scale as your business grows, becoming a Blueprint Agile founder is your best bet. This path strikes the right balance between adaptability and predictability, and it’s the approach that’s going to help you avoid the pitfalls I’ve seen time and again.
When You Should NOT Use Blueprint Agile
While I think Blueprint Agile is probably the ideal path forward for you, I also want to be honest with you. Blueprint Agile isn’t a silver bullet. It’s not the right solution for every project or situation. So, before you get too far into the process, it’s important to understand when it might not be the best fit. Here are some examples:
When Your Product Vision is Vague or Undefined
If you’re still in the phase of trying to figure out what your product even is, Blueprint Agile might be jumping the gun. This methodology works best when you already have a clear vision of your product and a deep understanding of the problem you’re solving. Without that insight, the ERB, IAB, and proof of concept will be little more than guessing games.
When You Don’t Have Subject Matter Experts Involved
Blueprint Agile is all about translating business requirements into an effective roadmap for your product’s design and development. To do that successfully, you need people who understand the problem you’re trying to solve—inside and out. If you aren’t a subject matter expert yourself, you need to recruit partners in this process who are. Otherwise, it will be tough to identify the right entities, map relationships, and create realistic user flows. You’ll end up with something that looks nice on paper but doesn’t actually solve the business problem.
Your Project is Highly Experimental or Iterative
Some projects are designed to be experiments from day one. Maybe you’re just trying out different ideas or you want to test new concepts to see if your audience would even be receptive to them. In that case, Blueprint Agile might feel too structured. The process is great for projects where you have a clear idea of what you’re building and need to create a roadmap everyone can work from. If you’re constantly changing directions or your project is in a high state of flux, you might find it difficult to stick to the phased approach that Blueprint Agile relies on to succeed.
You’re in a Time Crunch
Some projects literally can’t wait. If you don’t have time to complete product discovery, Blueprint Agile probably isn’t for your project. This process requires time—not a ton, but enough to carefully gather context, build the ERB, IAB, and validate a proof of concept before diving into design and development. If you’re under intense pressure and need something built in a matter of days, Blueprint Agile will feel like it’s slowing you down. You’d be better off with something more rapid, even if it’s less structured. If you have a few weeks to plan your product strategy, though, Blueprint Agile may be the perfect option.
A Note on AI
I’d be short-sighted not to mention the role of AI in all of this. The truth is, it’s already deeply reshaping how we build software and how product people think about their role in it. The principle I lived by for years no longer holds true. It used to take less time to design than to build. Now, with AI, it often takes less time to build.
This shift has massive implications. In the future, software development will be more commoditized. User experience designers will be more commoditized. Anyone who clings to their “craft” will eventually find themselves in a new career. AI will downsize the team sizes and the costs required to build software, at least in the early stages of a company.
In my opinion, the people who will thrive in this new era of software are the multi-disciplinary product leaders—the ones who can see the opportunity clearly, articulate the problem, and actually model the solution. That’s why this book exists: to give you a framework to do exactly that.
It’s also important to recognize where this book sits in the timeline of AI adoption. Right now, we’re in a short golden era—in between a moment in time when AI was not used to build software, and another moment when AI will be used to support all software development. Some people already get it. Most people don’t. This book will not explain how to be successful in a world where standing up a software company takes less time because of AI, but it will explain how to use AI to stand up a software company in less time.
At this moment in time there is an unprecedented opportunity for the non-technical founder—who is often the SME and product lead—to bring their vision to life like never before using AI. However, AI on its own isn’t enough. Without structure, its speed just compounds confusion. The principles in this book will help you take advantage of AI without losing sight of the fundamentals: context, clarity, and product vision. Blueprint Agile gives you that structure. The documents our process creates enable AI to build faster with less overhead and to test assumptions with greater speed and confidence, turning raw potential into real progress.
The Moment You’ve Been Waiting For
So now that you know how Blueprint Agile came to be, why it works for product discovery, who it’s best for, when you shouldn’t use it, I guess it’s time to get into the specifics of this framework. In subsequent chapters, we’ll go over each phase in Blueprint Agile, walking you through it step-by-step. By the time you’re through, you won’t just be an expert at Blueprint Agile—you’ll have a clear, actionable vision for your product that is validated. Remember, each phase builds on the one before it, continuously refining your product. It’s not about getting everything perfect right away, but about making steady progress.
