

Panic's Cabel Sasser on "Maximum Viable Products" - HenrikJoreteg
http://andyet.net/blog/2012/may/25/maximum-viable-products/

======
arkitaip
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.

~~~
emelski
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.

~~~
taligent
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.

~~~
gridspy
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.

------
jacobolus
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.

~~~
taligent
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.

------
apike
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.

~~~
SkyMarshal
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.

Seems to be the best of both worlds so far.

------
pirateking
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.

The key word is "viable", not "minimum".

------
acangiano
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.

------
zenogais
What the hell? This video is one minute long and has nothing insightful at
all. This is more an ad for your website than anything.

~~~
jarjoura
Yeah and Cabel's phone was going off the whole time. Clearly that part should
be edited out of the interview.

Panic is not even a startup, they are an established business that's been
around for a decade.

------
CubicleNinjas
Love this video!

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!)

------
FnF
This infographic illustrates your point <http://fundersandfounders.com/the-
minimum-viable-product/>

------
taligent
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.

