Minimum viable process | Hacker News Reader

Minimum viable process

themarketplace.guide

75 pointsrognjen35 comments

Part of the problem with the whole “Minimum Viable X” (MVX) is that it’s highly context specific to the point the definition varies from founder to founder and from user to user. I have yet to see a repeatable process for knowing if based on a specific situation if you’re currently under or over a true minimal viable X - or for the matter, assuming you understand the product space and related market, how to articulate to another how MVX and MVX2 for the same general intended end use compare; where MVX & MVX2 are either competing solutions or next evolution in MVX. Lastly, MVX generally significantly precede discovering product-market fit, but product-market fit in the end is the true MVX.

Said another way, most the MVX topic is about what not to do, which is helpful, but is not necessarily means to make progress on what to do.

What?!? You mean I can't just implement what I read in a book? ;-)

I mean, for myself, I am able to describe it in single sentence, though likely of no use to anyone else; that being:

Using observe-orient-decide-act-loop, minimize entropy creation for yourself, while maximizing future opportunities available relative to overall ecosystem dynamics.

To me "future opportunities available relative to overall ecosystem dynamics" reads as an euphemism for entropy, so that your advice seems to boil down to "let the others fuck up". Not a ineffective advice at that.

There’s no single optimal generalizable path, though completely agree that accrue value, move slow, reduce loses, do nothing, etc. — are frequently overlooked as more effective paths forward.

Better to parse it as "position yourself to be better positioned in the future as the environment changes" I think.

Maybe, though this is assumed via “overall ecosystem dynamics” and “ maximizing future opportunities available” - since in some situations having a less optimal position in the near future is the optimal response long term, though maybe you’re including “better” to cover that, but then to me better feels redundant.

Indeed.

Perhaps I misunderstood the general gist of Minimum Viable Product, but I thought it originated as a kind of test to determine whether what you had was actually a Product, and not just a one-off solution, or a piece of software, or some process that only a handful of people would ever actually pay for and use (hence the Viable part). Minimum was just guidance to not over-invest into any single part of the overall whole until all of the parts necessary for the Product were known. All of this would always be very specific to the particular Product.

Most people hear this advice and think it means they get to decide to cut corners, but what it actually means is that only your customers can tell you which corners they actually want; you never get to decide that for yourself.

To me a MVP is designed largely to be the first step after speaking to customers to validate what they say versus what the do. After you see what they’re actually doing, then you talk to them again and repeat process where each future action attempts to increase odds of building a sustainable, preferably high-growth, business.

Interesting! It seems like you view MVP as the process whereas I view it as a milestone (something like the bare-minimum version of “default alive”.)

>> I have yet to see a repeatable process for knowing if based on a specific situation if you’re currently under or over a true minimal viable X

Isn't the answer that shipping the thing is the only test? By shipping you figure out what's missing.

No. What you are describing is market research and it could be done a lot cheaper by not actually developing and shipping real software. Steve Jobs has a lot to say about what market research can tell you:

https://www.youtube.com/watch?v=2U3w5Blv0Lg

Your starting point actually matters quite a bit. Iterating to success through market research would be nearly impossible if you chose a bad starting point. Unless of course you go back to the drawing board each iteration. But in this case you aren't really testing and iterating, but trying out whole new things each round. I believe that if you are iterating in this way, then you truly don't have "it". You don't have whatever unique experience, product vision, perspective, etc is required to make the new thing that is going to disrupt the market you are trying to enter. You can't just keep trying things and get lucky in this way. At least not where we are in the cycle right now with software.

Another common way of criticizing the approach you’re referring to is commonly referred to as — “Build it and they will come” - which more often than not is done in a way that’s completely disconnected from reality.

I think "build it and they will come" has most of it's criticism focused on a lack of plan for doing more than making something. It is certainly okay to believe that you have a v0 for something brand new that once people lay eyes on it, they just need to have it. But that doesn't mean just building it is 99% of the work. It's more like 50%. And yes, more often than not the v0 does not work out this way. But this is the nature of doing bold things. They mostly fail. I think the startup ecosystem has sent the wrong message by saying it doesn't matter what v0 is, just keep improving it and you'll win.

In the musician world, "build it and they will come" would refer to creating a really great band by practicing in your parents basement, but never playing shows in the real world. You aren't going to grow a fanbase by playing in the basement. But you could be a damn fucking good band playing music that everyone needs to hear. There is a lot of work that takes you out of the basement. 50%. But if the first 50% isn't there no amount of leaving the basement is going land you anywhere.

Lack of planning has nothing to do with “build it and they will come” — and everything to do with communicating with the customer to understand what would make them come and why. Beyond that, this is not about getting a percentage done, but 100% of the least viable amount of “done” complete that would result in a predefined behavior; spend money, use product everyday, etc.

Musician equivalent might be identifying few notable bands in a given genre and actually understanding which fans spend money, why, where they listen to it, what other music they listen to, how they discover new music, what songs they share with people, etc; never done music R&D, so honestly stretch, in part because I know distribution is way more important than the actual music, but that doesn’t change that ultimately it’s the fans listening to music that matter. The “build it and they will come” would be making full album with music videos before ever letting single fan or peer familiar with fan tastes listen to the music.

communicating with the customer = marketing = a task beyond making the thing = my point.

No. It’s called customer development, product development, design thinking, human centered design, etc — and has nothing to do with marketing, which is something you do after you have a defined product or service. Sales has more in common with it than marketing.

Customer development, product development, design thinking, human centered design -- those all sound like made up activities you tell your VCs you are doing because you don't have product market fit with v0. Build a new v0 or go home.

The extract email from linkedin can be downloaded as a CSV file for automation purposes. The software https://chrome.google.com/webstore/detail/email-finder-getpr... can be used to automate email campaigns and track leads from start to finish

Simple answer is no, there is no answer, it’s never ending optimization problem that free ends way before product market fit is found and even if market market fit is found, it’s matter time before market shifts.

Another way of imagining it is if you look back in time, where hindsight is 20/20, assuming that as an observer you were aware of all factors. Magically you have a “Time Machine” and travel back time knowing the prefect way to do everything. Problem is the dynamics of the situation would evolve rapidly evolve and it would likely never stop evolving no matter how many times you completed the loop.

It seems like two or three things are conflated here. There’s process as in product development. There’s process as in your entire relationship with the customer. There’s process as in how your software fits into the customer’s greater workflow. All three are touched on, the last one seems the most interesting to me as a concept.

Thanks for pointing that out. It might have been good to be more explicit.

Running a marketplace involves lots more than a SaaS including things like direct sales and logistics.

Process here refers to those operational activities for which the platform is only the entry-point.

“yeah, I could be more explicit” is the response to like half of my critiques lol. Guess it says more about me than anyone else.

I think it's just a pronoun issue. In several places "your process" should be "the process".

A head of sales once explained to me (a dev at the time) how much there was besides building the product:

Imagine we built a Ferrari in our garage. So we try to sell it, but no Ferrari buyers want to go to our crappy house to look at it, and even those who do - go away when our wife with her 3 teeth grosses them out.

Basically, you can't sell a Ferrari for a Ferrari price unless you also have the Ferrari showroom and Ferrari salesmen.

To a lesser or greater degree this applies to every software product.

“They equate the software they built with the entirety of their product.”

The irony is that customers often exhibit the same way of thinking: “If only I had the perfect to-do list app I would be much more productive.” - they equate the solution to their problem with some product.

Ha! Good point. It's note-taking tools for me.

Interesting to contrast this with other start up wisdom, such as “ignore process until you have product market fit”. In any business with repeatable admin activities (payroll, fundraising, market research, taxes, accounts payable, onboarding) it seems important to streamline your processes so that you can make time to innovate and sell.

But perhaps this situation is unique to capital intensive slow moving industries like commercial real estate investment and development. I can see how software companies can get to revenue without processing hundreds of professional fee invoices and 1099s and paying filing fees for multiple entities. These activities are table stakes for real estate development.

Edit: I’m a property developer

Generalized, there two types of process development types: non-differential and differential. Ones that are non-differential should be outsourced as much as possible, ones that are differential should not.

The conventional wisdom you mention is suitable for a pure software play.

However, for a business that includes other factors, such as outbound sales for instance, process also needs to be iterated upon.

Unless it's taken seriously, maybe even more than the tech, the business is going to be of limited value.

As I mentioned in a reply to another comment, part of the value is being able to demonstrate that you can efficiently onboard thousands of suppliers each of which might have hundreds of products. This process is part of the PMF.

No all that is the same in modern SaaS startups. If you're not in the business of HR you don't innovate the HR. So everyone goes and uses Gusto or Rippling. Everyone uses Github. Everyone uses a Mac.

But the parts that you're aiming to innovate on it doesn't make sense. And that's all the actual pieces of business: your software, your sales and marketing, how you do customer success, etc etc

All that process has commonalities with other companies but ultimately has sufficient difference that experience is worth it to spot what to do, but you can't just copy. It's just like software in that sense.

The only exception are the "copycat startups" which see someone else hit PMF and then fail to scale the solution to capture the market. In that case, you go after their market faster without any of their legacy (not just in software, they may have large customers they do special deals with etc).

The normal expression is of course "Minimum Viable Product" which makes more sense. There's an easy trap for technical founders to fall into and think that the technology is the product, while of course it's not - the product is the value that users get from using whatever you are delivering, and process could be regarded as part of that.

I don't think what OP is suggesting is at odds with "ignore process until you have product market fit", since he says "do things that don't scale" - basically ignore process efficiency until you have a proven product/engagement.

Hey, I was looking to build something in the property space.

Would love your feedback if you have 15 minutes, email in profile

Thanks

Someone posted this link the other day.

http://widgetsandshit.com/teddziuba/2011/12/process.html

I must say I wholeheartedly agree with Rule 4.

Interesting take but we aren't talking about the same process.

You can't "Just let go" when you have to repeatably onboard thousands of merchants each of which might have hundreds of products.

Reply on news.ycombinator.com