MVP is an approach for startups that navigate in unknown and very risky waters, not knowing if they will even have paying customers. Now, we could certainly discuss the merits and validity of MVP but what the Coda 2 team does - web dev app a la Dreamweaver - seems so opposite to what startups have to go through that it makes sense that they go for "maximum viable products". Also, once you move beyond the first big release of your product (which Coda 2 has) I'm not sure you can create a mvp anymore.
You can use the MVP concept, even on a very mature product. You just have to adjust the scope of the idea. For example, my product has been in development for more than 10 years and has had 24 major releases. Yet when we are considering adding a new feature, we still scope the work in terms of the minimum usable version of the feature, as well as the "100% version", hopefully with a few reasonable steps in between. This enables us to focus on getting something useful out quickly, in order to validate the feature, while avoiding gold plating until we have that validation.
I hope anyone who is building a startup never listens to your advice.
Putting the minimum effort in and building effectively mediocre features is not how you build customer loyalty and excitement in the market place. And it makes it very easy for competitors to go after you. Sure you should keep the scope tight but you should try and at least make it highly usable. Even if its just so you can sleep at night knowing you made something great.
I hear what you are saying: make quality, complete products.
However, a minimum viable product basically means 'ship something and iterate towards complete.
Considering how many products I have worked on that no one ultimately wanted, you need to prove there is a need for your product BEFORE spending man-years on it.
Even if you understand the problem, putting a simple solution in front of your clients will teach you a lot.
Then two years later, you might be approaching something complete, but with confidence that there really is a market.
It's not about putting in the minimum effort. It's about getting something usable out quickly and gathering feedback from actual users not only to validate the idea, but to ensure that the next steps we take are in the right direction. There's nothing to be gained by building in a vacuum, or polishing a product or feature for months or years, only to find out at last that you built the wrong thing, or that somebody else beat you to the market with something that was "good enough" while you finished your magnum opus.
There's an exception (or five) for every rule; I think startups should be distrustful of one-size-fits-all business models. It's all about defining and managing your customer relationships.
Of course, one noteworthy truth is that Panic had/has existing income streams that allow them to take their sweet time pursuing perfection. The majority of startups have a fixed quantity of runway, making MVP the better choice by default.
I wanted to say I really like how you summed your thought up. You made a lot of sense, and I completely agree.
We created something that was first released as an MVP (and we made sure that was clear for our customers). Now that we know we have customers, and we know people are willing to pay... we're taking our time to make sure we do the rest of it right. And so far, our customers have been very understanding, patient, and helpful through the process. Something I didn't think would be the case.
The problem I have with the Coda approach, which is shared by other IDEs (and plenty of other kinds of software too), is that the interface components are overly specific to particular workflows and environments, and each tool complects multiple features/concepts. This (a) makes it harder to learn each individual part, (b) makes composing those parts to meet personal needs more difficult, and (c) makes it so learning those tools doesn’t point toward anything greater – you can’t take what you learn with you to new environments that weren’t anticipated by the original tool authors. Additionally, these kinds of tools tend to isolate users from the systems underneath, creating dependency. I much prefer when tool-builders think long and hard about making simple, orthogonal tools, designed to be composed together to meet diverse needs. As long as the individual components are explorable, such tools teach their users more fundamental concepts and allow them to grow over time.
When implemented well, an environment like Coda can be very productive in the niches for which it was designed, but in only offering a standard workspace and set of tools to everyone, it denies users the chance to build their own workspaces and pick & hone their own tools. This infantilizes and shelters those users, limiting them in the longer term.
The workflow actually doesn't help in typical usage either.
- Edit a file remotely. You make a change and save it. It auto publishes that file. Makes sense, right ?
- Now you want to have those remote files also in Git. So you copy the remote files locally. However you make a change and there is no way to auto publish. And no way for it to be changes to be automatically added or committed to Git. And the add/commit UI behaviour is clunky. Meaning it is in fact quicker to use the command line defeating the whole purpose of Coda.
Minimum viable product does not mean a product shipped as fast and cheaply as possible. I see a lot of projects announced as a MVP, that can barely even be called a finished product. If you are building a quick project because you just learned a new technology, it is not a MVP - it is an experiment. A true MVP is something closer to "as simple as possible but not simpler", which as everyone knows can be time consuming and difficult. It is the simplest product that can fully achieve its intended goals.
This highlights the core tradeoff when developing a new product.
"Don't waste time" vs. "Don't ship crap"
"Fail fast" vs. "Wow your customers"
"Ship early, ship often" vs. "Sweat the details"
The MVP philosophy focuses on the left side. The Apple philosophy focuses on the right side. Leaning to the left side is efficient, and might be necessary to stay alive. Leaning to the right side can be immensely satisfying and profitable.
A lot of companies can only afford to fail fast. However, if you can afford to sweat the details like Apple or Valve, there's nothing else like it.
Apple sweats the details, but overall they're very selective about which details to sweat, to the exclusion of all else.
They're realistic about the fact that you need to ship, and that if you want to both sweat the details and ship, you've gotta focus on a few core features, and either nix all the others, or put them on the roadmap for future builds/patches/expansions.
There is more than one way to achieve a positive result. I think a minimum viable product makes a lot of sense for an early stage startup that is still validating their idea on the market. For a well established product like Coda or TextMate, you usually want your next edition to satisfy many of the needs of existing customers and motivate them to upgrade. Of course, this is not to say that you can't still use the minimum viable product approach. You just can't rule out doing the opposite just because it's not Lean. For established companies it can work.
The problem with this approach is if the market responds negatively. I feel this way right now with Coda 2, as it feels over designed and targeted at an odd-case web developer. I truly hope I'm wrong with Coda 2.
But the point remains, if you swing for the fences and miss with a MAXVP then don't be surprised if you go back to the minor leagues. (I made a sports reference nearly successfully...I'm calling everyone I know!)
Panic really needs to keep its mouth shut about MVP.
It is not some tiny startup. They are one of the leading 'shareware' makers on the Mac platform. And the fact is that Coda 2 is a buggy mess with many of its key features completely unusable. I fail to see how with this sort of approach it is going to ever build customer loyalty.
