Thomas Rolley 00:00
The dangers of minimum viable products.
Now, this is an interesting conversation. Let me just adjust the camera a little bit.
I've just been on two adventures into minimum viable.
And one of the big takeaways is setting at the beginning what the minimum is.
Because it is incredibly easy to get excited about what's possible and start adding features.
This happened to me, so I'm going to be twice in two separate ways.
One is that I expanded the product, and I was like, Oh, I could do this and could do this.
Well, this is clearly necessary for the minimum product was the thought that went through my head.
But, when I look back, I'm like, that wasn't minimum at all.
That was an extra feature; that wasn't an added thing that could have come later.
Instead of saying, No, this is minimum.
And remember, at this minimum viable product stage, nothing has been proven. You have no information. I have no information at that point.
And so going in expanding this thing, because I think it's going to work, I think it's a great idea, I think it's part of minimum has a couple of consequences.
One is that the test becomes diluted.
Because it's no longer a minimum, but it's a minimum with some stuff, the actual test that the minimum viable product was meant to do gets congregated like cotton. I don't know what that word is mixed up.
It's mixed up, you've got the minimum, and you've got the plus you like, well, now I've got a problem in assessing.
So what I'm taking from this is what I should have done, and perhaps you would do as well, is to be very clear on what you are testing, what am I testing? Oh, we are testing this, and building for that specific thing, and then going to real people and saying, Hey, what do you think of this? Allowing them to use it allows them to give you feedback because as soon as it goes beyond that minimum into the minimum plus features, they might give you interesting feedback.
But the actual test you're trying to meet that I'm trying to do with my minimum is lost.
Also realize that this costs you more money, it increases the number of bugs, it increases the number of difficulty, it takes longer to get to a bigger app of biggest software, then just the minimum.
The second very interesting thing that was brought to me was that because software's pretty fun, like, if you're in software design, it's fun, it's cool, it's very easy to fall in love with creating more stuff.
And what I found was I was creating things for which there are already proven solutions.
And what I mean by this is that somebody has already invested a whole lot of time and money to come up with a piece of the puzzle that already does that particular thing.
So things like support desks and things like roadmaps, there is already software that does this.
And it is infinitely cheaper to go from a link that says support and it takes them to that other piece of software that's already done that already has support that already works.
That's a whole lot of a better solution than trying to build a support desk.
Because I got too excited in the app.
I'm like, oh, cool, never stopped to think and say, Hey, is this necessary? And this really feeds back into that first question as well.
Like is this minimum is a support desk, even minimum? No, it's not, shouldn't have even been in there at all.
But if you didn't want to do that, then remember, there may already be pieces of the puzzle that are done and you can just put a link across to that support desk or link across to that roadmap.
There's a whole lot of things that have already done.
So this is the learning from minimum minimum viable product.
Thomas Rolley 04:33
What is the minimum defining minimum is the critical takeaway, otherwise you will spend more money take longer and mix up your results you don't even get a pure test.
Next up, remember if there's pieces already done, use them, use them.
And as a last parting thought, I would invite you to think that hey, you know, at a minimum viable Why do you think have a support desk, why do you have a roadmap you're not looking for that at this stage is looking for, hey, does this give a yes for people to say, yeah, I get it, I get it, I get what this is about.
And then fine, you can move to beta.
That's been my experience.
Like it's, it's kind of fun.
Like, as you may or may not know, I'm a doctor and have this software piece in my life.
It's of great benefit.
It's very different to consulting with people and solving their problems.
Software is brutally rigid.
It's like, Hey, you wrote the code like this.
This is what happens if you not if you wanted something different.
There's a problem with the code.
So there's very different from human beings.
I hope you got a lot of value out of this.
If you are thinking about a minimum viable, then do some work in terms of defining the question, defining the minimum before you go anywhere near a Figma or a user story or developer, any of that stuff.
Make sure you are clear on what you are trying to find out with this minimum viable product.
I look forward to seeing you on another episode as we finish up here. If you need some help with your systems and making them work in your business, and that's what the purpose of the app is to head over to the systemio.dev look forward to seeing you soon.
