Efficient and effective SaaS MVP development takes imagination, discipline, process, and above all, customer feedback. I recently met with a company that demoed what they were calling an MVP-stage product. In reality, it was a wireframe-stage product developed in a vacuum from actual, potential customers. They’d been at it for years, had yet to launch, and were into a few seed rounds — all without user feedback.
As you may know, I am a CEO with a marketing background. I’m not a product manager, nor a CTO, and certainly not an engineer. But I’ve been directly involved in web-based software development since the late 90s. Most of that was done lean, and in highly competitive spaces (like marketing technology (martech)). And, in the early 2000s, I was hands-on designing and blueprinting content types, information architecture and UX for our web-based CMS. I know what worked for us across several products and thousands of customers.
The More SaaS MVP Development You Do Without User Feedback, The More You Will Redo
User feedback on actual software is incredibly valuable. The earlier you can get that feedback, the better. But, a minimally viable product (MVP) is hard to actually release. Why? Because what is minimally viable isn’t easy to agree on. And, as you slip features and polish into your MVP, you delay its release and your precious user feedback. The longer you wait to release your MVP, the more you will redo. You will have made choices on behalf of users that were just plain wrong. And you’ll have to fix them.
Rapidly iterating your MVP based on user feedback is critical to getting to something you can release as a public or invitation-based alpha. If your rapid iteration phase extends too long because of retooling an MVP that was too deep, you are likely to cost yourself time-to-market (and revenue). If you want to pay for development more than once, then over engineer and over design your pre-launch product. If you want to reduce your time-to-revenue, contain your engineering budget, and improve your customer retention, stick to a tight MVP and get faster feedback.
Iterating Your MVP Means Listening Carefully
Here I’ve been harping on getting user feedback and I’m about to tell you to discard some of it. The challenge is in deciding which bits to discard and rapidly iterating the rest back into the product. The more cycles you can execute, the faster you will get to something that’s feature-complete for alpha. Again, ‘feature-complete’ becomes a slippery slope, but time-to-revenue is a mighty motivator for most startups, so you should be able to keep the scope in check.
We always listened very closely to the customer. But, we didn’t do everything they asked. We listened for patterns and repetition, looked for crossover between related issues and cross-tabbed that with our own worldview of market innovation. Once we saw a problem or opportunity with enough critical mass, we cycled through solutions to get something back into the product for another round of feedback. If a change was large enough, that may have meant cycling back one more step and taking select users through wires or mocks of alternatives before choosing the path.
My Four Greatest Temptations in SaaS MVP Development
1. SaaS MVP Feature Width Scope Creep
I alluded to this one earlier, but letting your minimally viable product (MVP) turn into anything beyond minimal is a big mistake. There’s always something else that could be baked into your MVP. But could isn’t should and widening the scope will slow development, delay feedback, complicate iteration, and cost you capital and revenue. So, every decision to widen scope has to be thoughtfully and openly weighed against those downside risks. This is hard. And I have personally presided over too many MVPs that got out of hand. Take it from someone who’s made this mistake more than once — stay minimal and get fast feedback.
2. SaaS MVP UI Polish
It’s amazing how finished some MVPs look and how foolish that is. The most critical feedback to get back quickly is function and user experience (UX). The user interface (UI) investment you make before your basic value prop and UX are validated with users is a premature waste of time and money. You can field a functional MVP far faster with off-the-shelf, prototype-standard UI (that still looks good) and then apply your amazing, differentiated design after your rapid iteration. Again, I’ve made this mistake — spending unnecessary weeks or months on debating UI elements, colors, and fonts within the MVP. Don’t get me wrong, shorten your overall dev cycle by running your UI work in parallel with your MVP. Just don’t comingle the two. You can design and mock your UI system outside of your MVP and then merge it in when you’re feature stable.
3. SaaS MVP Feature Depth Scope Creep
MVP feature depth is different to me than overall scope creep. Keeping a feature set narrow is the most obvious path to scope control, but keeping that narrow set of features shallow is another. Depth may be the more insidious temptation and the one that’s harder to see as it’s happening. I’ve sat in many meetings where groupthink led to the justification of bolting too much onto an MVP feature without prerequisite user feedback to even validate that the top-level feature is valuable. More often than not, those premature bolt-ons were unbolted or seriously modified based on user feedback. It’s very easy to justify pre-MVP feature depth as required polish for the user to “get it”. I’d prefer to wait for them to tell me the core capability is valuable but needs x, y, and z.
4. SaaS MVP That Forgets Who the Customer Is
I’ve seen MVPs clearly focused on their ideal customer profile (ICP) and many others that just flat out miss their target. The most common missteps here occur when the MVP feels by and for engineers or by and for the CEO. ICP focus swings the pendulum back toward a bit more MVP investment to ensure that it’s going to play to its intended audience. It can be resource-consuming to ensure your MVP has a user experience that aligns with target expectations. But that’s critical to getting valuable feedback. Truth is, you’ll know if you botched this one right away because they won’t get it and it won’t be discoverable for them. Unfortunately, you may have a long road to retool enough to make it fundamentally approachable. This is another great reason to keep things moving and get feedback fast.
Imagination, Discipline, Process, and Feedback
To reiterate, efficient and effective SaaS MVP development takes imagination, discipline, process and user feedback. Today, I’ve focused on keeping the early part of the process agile and user-focused. In my experience, keeping the MVP directed toward rapid iteration based on user feedback is critical to launching fast with a solid market fit.