How many MVPs does it take to fix a broken delivery process? The answer, unfortunately, is 'none'—because while MVPs excel at testing products and technologies, they can't address systemic issues in how your organization delivers value.
As consultants embedding into organizations, we need to quickly understand existing delivery processes and identify areas for improvement. Our clients look to us to help uplevel their engineers and streamline processes, to lead them to value faster and more efficiently.
It is easy to get lost in what to ship, but taking time to consider your approach before jumping into action can be a game-changer. (At Test Double, we like to call this part “thinking really hard"). Under pressure to meet tight timelines, teams often find themselves constantly firefighting.
A common manifestation of this challenge is organizations repeatedly launching different MVPs with inconsistent approaches, hoping to discover an effective delivery process along the way. Teams often focus on what to build rather than optimizing how they build and deliver software.
Yet the result is often the same: software that remains separate from core business processes instead of being integrated into them, with scaling limited by human bottlenecks rather than technical constraints.
Sound familiar? If so, this is where shifting your focus from Minimum Viable Product to Most Valuable Tactic becomes transformative. While MVPs help you deliver something quickly to test market fit or evaluate a technology choice, the MVT helps you address the fundamental approach that will make all your delivery efforts more effective.
The MVT approach
The most effective tactics often challenge deeply held organizational assumptions—those unchallenged practices that persist simply because 'we've always done it this way.'
If you find yourself in a similar situation, it's worth taking time to stop and think critically about the most valuable tactic (MVT) for your organization. Ideally this should precede any development efforts; you may need to stop shipping MVPs in order to focus on identifying your MVT, and this may need to happen multiple times as your organization evolves and grows.
Context matters, and you will need to consider the stage of your organization, the maturity of your product and engineering teams, and past decisions that have led to the current state of affairs.
When rewrites aren’t the answer
Perhaps your organization is struggling under the weight of continued rewrites of systems. While well intentioned, these rewrites often repeat the same mistakes of the systems they are replacing, fragment knowledge and create silos, and create technical and organizational debt that severely limits your ability to scale and innovate. Your MVT in this situation might be to take inventory of existing systems and processes, identify areas of overlap, and plan and execute a series of smaller surgical refactors instead of starting from scratch.
Taming legacy system sprawl
Or perhaps you are seeing some value in the MVP approach, but you are being hamstrung by legacy systems that are difficult to maintain and are never formally deprecated. Your MVT in this scenario might be to come up with a clear plan and timeline for deprecating these systems, ensuring that you have the ability to shed technical and organizational debt at the same time you are delivering new features.
Breaking through communication silos
Do you find your organization suffers from a lack of documentation or has multiple communication silos? Wiki sprawl and fragmented use of tools by different teams often leads to communication breakdowns, misunderstandings, and inconsistent practices. Your MVT in this situation might be twofold: first, consolidate your third-party tools. Second, shift away from comprehensive written documentation toward visual aids—diagrams, flowcharts, and interactive prototypes—that improve collaboration and understanding across teams.
Protecting focus and flow
Frequent context switching and a lack of focus time are challenges that MVP development can’t solve. If your team struggles with this, your MVT might focus on emphasizing asynchronous communication over mandatory meetings. Empower your team to decline non-essential meetings, block dedicated focus time on their calendars, and share information through brief screencasts instead of requiring real-time attendance. These tactics can help preserve the deep work essential for quality software development.
Signs you need to focus on MVT
If you recognize these signs in your organization, it's time to shift your focus from what you're building to how you're building it.
Team dynamics
The most telling signs you might need a tactical overhaul often manifest in your team's dynamics. Maybe you have noticed that adding more engineers to the team actually decreases velocity rather than improving it—a classic scenario that Brooks's Law predicted in 1975. This counter-intuitive result typically stems from coordination overhead and process inefficiencies that become more pronounced as the team grows.
Knowledge silos emerge where critical information becomes concentrated in a few key individuals, creating bottlenecks and risks. Your engineers might find themselves constantly context-switching between different tasks or responsibilities, disrupting their flow and reducing overall productivity.
When you realize that your team is spending more time in meetings discussing work than actually doing it, it's a clear indicator that your tactical approach needs to be revised.
Process issues
Look closely at your development processes and you will often find recurring patterns that signal the need for tactical improvement. Technical challenges that seemed solved in previous projects mysteriously resurface in new ones, indicating a lack of systematic thinking. Perhaps you have noticed that when you implement improvements in one area, unexpected problems crop up elsewhere, suggesting interconnected issues that need a more comprehensive approach to address. While documentation may exist, it may often sit unused or undiscovered when needed most. Perhaps most telling, you find multiple teams independently creating different solutions to the same underlying problems, indicating a need for better collaboration and shared approaches.
Scaling challenges
Growth exposes tactical weaknesses in organizations. Manual processes that served small teams become bottlenecks at scale. Technical and organizational debt accumulates faster than teams can address it, hampering new initiatives. Lengthy onboarding processes delay productivity of new hires. Critical systems powering core business functions strain under increased load while teams prioritize new features over strengthening existing foundations.
Implementing MVT thinking in your organization
Taking the time to identify and implement your Most Valuable Tactic requires courage—especially when there's pressure to deliver quickly. But by prioritizing how over what, you'll create a foundation for sustainable delivery that no MVP alone can provide.
As you begin examining your organization's tactical needs, consider what patterns emerge from your past delivery attempts. Look carefully at where your true scaling limitations originate, and identify which processes, if improved, would amplify the value of everything your team builds.
The MVT approach doesn't replace the need for MVPs—it enhances their effectiveness. By identifying and addressing your fundamental tactical needs first, you create an environment where your MVPs can actually deliver on their promise of rapid learning and value creation.
As consultants, our greatest impact often comes not from the features we ship, but from the tactical improvements we leave behind—the sustainable approaches that continue delivering value long after we've moved on to our next engagement.
What's your organization's Most Valuable Tactic? It might be the most important question you haven't asked yet.
Quick start: Begin your MVT journey by scheduling a "tactical review" meeting. Spend one hour listing every friction point in your delivery process, no matter how small. Look for patterns——they often point to your most valuable tactical opportunities.
Related Insights
Learn how to use external data with different naming conventions in Python with Pydantic. The guide covers different approaches and pitfalls using Pydantic's alias and alias generator features.
