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 designing beautiful user experiences. 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 the hundreds of projects since, taught me a few core principles: It takes less time to design than develop. It takes less time to flowchart than design. And it takes less time to model data than flowchart. Blueprint Agile was born out of these insights—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 taking your product idea from that sketch on a napkin to a real, viable product.
So, Why Blueprint Agile?
In an agency setting, you’re often pulled between two worlds: Waterfall and Agile. Most 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. 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.
Agile, on the other hand, takes an iterative approach, breaking work into smaller cycles or “sprints” to continuously deliver new value and allowing for flexibility as the product evolves. This adaptability makes Agile great for integrating feedback as early as possible in product development. It has one major problem, though: it’s tough to predict. Agile can lead to scope creep, missed deadlines, and unexpected costs if you’re not careful, and when you’re working with clients, 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 each phase follows 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 it 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 traditional approaches to product discovery spend too much time obsessing over the myth of perfection, 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 four key parts.
- 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. I’ll discuss the ERB more and walk you through the process for creating one in Chapter 2.
- 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. I’ll go into the details of building an IAB in Chapter 3.
- User Flowchart: The user flowchart visualizes how users interact with your product, guiding both the design and development teams in their efforts. This flowchart ensures everyone is on the same page about the user journey and system responses. In Chapter 4, I’ll show you how to create flowcharts that capture these key interactions.
- Synchronized Delivery: In this final step, design and development happen simultaneously, ensuring that the product vision remains aligned throughout the process. Synchronized delivery helps accelerate the project timeline and ensures that both teams work cohesively. I’ll dive into how to effectively manage this in Chapter 5.
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 what they’re building. 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. 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 planning, no strategy, 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—at least on the frontend.
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 reinstall the tile in your bathroom five times.
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 an unpredictable environment where scope creep, sloppy work, and mismanagement have an opportunity to 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 don’t actually work the way they should.
Architect founders tend to underestimate the complexity of the software, resulting in poor data model decisions that also need to be refactored. 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.
Hopefully, You’re a Blueprint Agile Founder
The Blueprint Agile founder takes a more enlightened approach to leadership. This is the founder who understands the value of taking things step by step, building confidence at each phase without getting bogged down in perfectionism. They start by creating and validating an ERB and an IAB before creating a flowchart, and then 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 flowchart 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 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 serve its purpose.
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 solid 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
If you don’t have time to plan, Blueprint Agile probably isn’t for your project. This process requires time—not a ton, but enough to carefully build the ERB, IAB, and flowchart 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.
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. 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.
