[HN Gopher] Minimum viable process
___________________________________________________________________
Minimum viable process
Author : rognjen
Score : 65 points
Date : 2023-02-05 14:38 UTC (8 hours ago)
(HTM) web link (themarketplace.guide)
(TXT) w3m dump (themarketplace.guide)
| xyzelement wrote:
| 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.
| shanedog wrote:
| 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
| renewiltord wrote:
| 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).
| HarHarVeryFunny wrote:
| 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.
| O__________O wrote:
| 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.
| moneywoes wrote:
| Hey, I was looking to build something in the property space.
|
| Would love your feedback if you have 15 minutes, email in
| profile
|
| Thanks
| rognjen wrote:
| 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.
| lstodd wrote:
| Someone posted this link the other day.
|
| http://widgetsandshit.com/teddziuba/2011/12/process.html
|
| I must say I wholeheartedly agree with Rule 4.
| rognjen wrote:
| 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.
| travisjungroth wrote:
| 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.
| rognjen wrote:
| 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.
| travisjungroth wrote:
| "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.
| danielmarkbruce wrote:
| I think it's just a pronoun issue. In several places "your
| process" should be "the process".
| Hamlet42 wrote:
| "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.
| rognjen wrote:
| Ha! Good point. It's note-taking tools for me.
| O__________O wrote:
| 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.
| w1sem4n wrote:
| >> 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.
| enos_feedler wrote:
| 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.
| O__________O wrote:
| 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.
| enos_feedler wrote:
| 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.
| O__________O wrote:
| 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.
| [deleted]
| enos_feedler wrote:
| communicating with the customer = marketing = a task
| beyond making the thing = my point.
| O__________O wrote:
| 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.
| O__________O wrote:
| 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.
| presspot wrote:
| What?!? You mean I can't just implement what I read in a book?
| ;-)
| O__________O wrote:
| 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.
| lstodd wrote:
| 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.
| beckingz wrote:
| Better to parse it as "position yourself to be better
| positioned in the future as the environment changes" I
| think.
| O__________O wrote:
| 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.
| O__________O wrote:
| 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.
| jt2190 wrote:
| 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.
| O__________O wrote:
| 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.
| jt2190 wrote:
| 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".)
___________________________________________________________________
(page generated 2023-02-05 23:01 UTC)