Live data from Hacker News

Panic's Cabel Sasser on "Maximum Viable Products"

andyet.net

11–19 of 19 posts

Re: Panic's Cabel Sasser on "Maximum Viable Products"

#11

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…

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.

Re: Panic's Cabel Sasser on "Maximum Viable Products"

#12
post #7

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.

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.

Re: Panic's Cabel Sasser on "Maximum Viable Products"

#13
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.

Re: Panic's Cabel Sasser on "Maximum Viable Products"

#14
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".

Re: Panic's Cabel Sasser on "Maximum Viable Products"

#15
post #13

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…

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.

Re: Panic's Cabel Sasser on "Maximum Viable Products"

#16
post #5

Earlier quoted context omitted.

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. T…

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 y…

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.

Re: Panic's Cabel Sasser on "Maximum Viable Products"

#17
post #5

Earlier quoted context omitted.

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. T…

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 y…

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.

Re: Panic's Cabel Sasser on "Maximum Viable Products"

#18
post #5

Earlier quoted context omitted.

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. T…

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 y…

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.
Post reply on HN