An MVP Philosophy
For every project, large or small, I strive for a Minimum Viable Product (MVP). For those not familiar with the term, it’s an initial launch scope that focuses on the core functionality necessary to deliver value to you and your target audience.
It’s a principle rooted in software development, but I find it also applies to marketing and new products.
Don’t wait for perfection. Get out there and iterate.
My Process
I have found that the steps are straightforward, but many organizations just don’t follow them. They’re eager to see results from a big idea and dive straight into execution, only to discover roadblocks and strife.
I don’t want this to happen to you. I will guide your team through each phase, coordinating efforts across departments and documenting each step of the way.
Agility is having a process and plan, plus being responsive to change.
The idea is to align early and squeeze out the uncertainty on our way to your MVP.
- Assessment & Diagnostics is where we augment what you already know with what you need to know. We identify and interview stakeholders, establish benchmarks, and uncover any resource or technical gaps that must be considered.
- Strategy uses the diagnostics to drive consensus on goals, KPIs, launch priorities, MVP scope, decision making roles, guiding principles, communication methods, and change management.
- Planning uses these inputs to develop your project plan and roadmap.
- In Execution, we work the plan and provide regular stakeholder updates.
- Launch is both the end and the beginning. We will celebrate the successful launch of your MVP and start gathering data to inform longer-term strategies.
- From there, we drive Continuous Improvement.
Why it Matters
Every launch comes with noise and bumps. (The actual launch is the loudest part.)
A disciplined process (led by someone who’s been around the launchpad a lot) helps set expectations, keep things on track, and calm the nerves of any first-time flyers.
A few more things I’ve learned along the way:
- You’d be surprised what people will tell an outside person vs. their internal leader (see: what you need to know in step 1).
- We’re coordinating the efforts and emotions of multiple teams. This is often best done by an objective outsider.
- Staying on time and responding to change require smart prioritization. This can’t happen without upfront agreement on what matters and how it’s measured.
- Translating business needs into technical requirements is harder than it seems. Ask anyone who’s said, “That’s what I asked for, but not what I wanted.”
- Role clarity is critical! For example, owning the product and owning the project are not the same. And “stakeholder creep”—bringing in more and more opinions—is another risk.
- New programs require new processes—both strategic and operational expertise are a necessity.
- Documentation is your friend, especially when things get bumpy.
- And yes, there may come a time to throw out the user manual and improvise. That’s where you’ll need the help of:
- Sound judgement based on tech expertise and experience.
- Quick decisions (read: role clarity).
- Guiding principles. (Good thing we established those in the Strategy phase!)
