Due to the lose definition of the term ‘MVP’, we oftentimes confuse our teams on the status of the product and what it can deliver. How Engineering thinks about an ‘MVP’ is very different to how Sales or Marketing think about it.
@Santi, Co-Founder & CEO at Momentum has a fascinating approach to create alignment and I am excited to share our full conversation with you.
✅ Versioning with purpose: Utilize a structured versioning system (0.1, 1.0, 10.0) to clearly communicate the stage of product development and set expectations across teams.
✅ 0.1 for demos: Version 0.1 signifies that the product is ready for demonstrations and sales, even if it may not fully work in all scenarios.
✅ 1.0 delivers value: Achieving version 1.0 means the product delivers real value to customers and is ready for broader usage and billing.
✅ 10.0 for love: The leap to version 10.0 involves significant effort, aiming to polish the product to the point where users absolutely love it.
✅ Granularity aids clarity: Adopting more granular versioning within different components or features of a product can provide clearer guidance on development focus and progress.
Santiago (00:00)
Yeah, sure. So hi, I'm Santiago Suarez-Ordonez. I'm an Argentinian born and raised. I'm the CEO of Momentum. We are a product in the sales tech stack. We bring in AI and automation to help sales teams get more work done without having to dramatically grow the workforce. I'm also a developer by trade.
I've been building products and managing tech and technical debt over years and I'm on my real first stint out of a technical seat doing sales and focusing, you know, the closest I've gone to engineering again in the last three years has been on the product side deciding and deciding what we do next in the roadmap as a company.
Jack (00:47)
Super interesting that journey from kind of engineering to sales and seeing it all, I guess, and lots of interesting experiences there. But I think we were just talking like off air about a really interesting approach that I'd never heard of, which is how you guys think about versioning and what you're launching to customers. Tell us a little bit about that.
Santiago (01:09)
Yeah, you never heard of it because I came up with it. So it's, it's only, it's actually not completely only in my head. I wrote about it. Um, uh, I forget how long ago it must've been a couple of years. Um, we, the problem that I was trying to address when we came up with this approach and it's actually, we stood the pass of time for, for quite a bit.
Um, is the usual disconnection between people's interpretations of when a product will be ready. Right, you say you're going to build a product and you have engineering have a bit of a implied understanding of what they're going to go build and when they're going to call it complete, then you have sales and marketing. And of course the rest of the company all expecting something to ship that usually is not exactly aligned. I found that MVP was a pretty loose definition. Everybody has a different interpretation that even one of the MVP really.
Yes, so we at momentum, actually my past company, and then we brought that into momentum. We decided to use versions where versions by themselves carried a meaning of what the product accomplished.
Jack (02:17)
Yeah, I think that makes a lot of sense. It's like reminding me of this meme where it shows the horse in those three phases. You know, it's like what marketing is expecting, what the PM thinks it's going to be, and then what engineering actually ships. And it's just like the horse getting progressively uglier or less high definition, let's say. And unpack those three different kind of versions for us or how you think about those.
Santiago (02:40)
Exactly. Yeah, so we have, there's three important versions to understand and kind of, there's a continuum between the versions, which makes it even more fun of a framework, but to start, there's three key milestones and three key versions that we connect to those, which is how we try to position ourselves in the continuum of versions.
We have a 0.1 version of a product, it's usually our very first release, and what 0.1, implies inside my company is that the product is ready to demo, is ready to be sold What's interesting about that is it just has to look like it functions. It doesn't necessarily have to actually fully work. It needs to work perhaps in a very concrete case so you can give a demo end to end and it works.
But what it doesn't do, which is very important and everybody understands in my company when we say we're launching in 0.1, is deliver real value to customers in the field.
For it to really get to deliver value in the field, there's a ton of work you've got to do. So our next version is 1.0. And what's interesting about it is you could think of almost like as if 1.0 is 10 times the effort at 0.1. It's quite easy to put together something that demos. 10 times was hard to put together something that delivers enough. So that, to us, is valuable. You install it. It does the job. You're happy. You don't hate it. You don't love it either.
You're happy with what you got. And that's when we really start charging people money for it and we progress. And then the next big version, which I rarely go after, is 10.0. 10.0 for us, which is 10 times larger than 1.0. 10.0 is the light, is the polish, is all the work that it really takes for somebody to get their hands on the product and absolutely love it. And I love that these versions actually kind of imply how 10.0 is.
100 times harder and requires 100 times more effort than 0.1. But perhaps the only caveat that I'm going to add is there's a continuum between these. So on a side momentum, when we're talking about products and what are we going to invest in the next two weeks, sometimes we say, Hey, we're going to get this product from 0.1 to 0.3, or we're going to get it from 0.3 to 0.8, or we're going to get it from 1.0 to 1.5, and we're all kind of understanding that in the demoable and valuable, we're going to get halfway there. And it's become a bit of a language we use quite a bit. And it's, I think it's very convenient because there's just so much that people usually misalign themselves on this front.
Jack (05:24)
Yeah, I love that. I love that because I think it's so, so interesting, even within our team, we're like, you know, oh, is this thing launching? It's like, yeah, it might be launching, but it might be a massive, you know, it might be a massive piece of shit at that stage, right? And it takes a long time to get to get it to something more real. But I, you know, I'm thinking about our case as well. And I think a lot of cases that involve machine learning or AI stuff, which is like, maybe you've got something there, but you need to optimize it, right?
And like you're you know, your front end might work, your back end might work, but you might have a model or like the outputs of a model that are very nascent. And I think it's helpful for being like, you know, maybe the back end and the front end is actually at 1.0, but like the rest of it is at 0.1. And I guess then, you know, you're not just saying, Oh, we're at MVP, but you're, you're actually speaking a language, which is much more descriptive, essentially.
Santiago (06:06)
Exactly. It's a little more granular is the core idea. And you can version parts of a product. You can version products in a platform. We add a lot of, we just put versions all over the place. And when we're road mapping, we're always saying, we're going to get this product 0.5, and then we're going to get this product from 0.3 to 1.0, or this one. We're going to launch it at 0.1.
Sometimes we very rarely launch a product at 1.0. We usually start with 0.1,l because it's just so much cheaper. And being able to demo a product gives you concrete feedback from the market on whether you should really build it, which is ultimately 10 times more expensive.
Jack (06:58)
Absolutely. And does everyone in the team then use the same language? Is that like used across marketing as well as in product and engineering or is that kind of just within product and engineering?
Santiago (07:09)
No, it's marketing gets involved too. Sales understands it when we go tell reps, hey, we're gonna launch so-and-so products, 0.1. They understand they're gonna be able to give a demo, but if the customer wants to like do an in-depth demo, that's probably a bad idea.
We try to align everybody around this under certain degrees of accomplishment on that journey, but I'll say it's been a lot more useful than just saying, is it MVP or is it final? Which is the way most companies tend to communicate about this stuff, which is too broad a stroke in my book.
Jack (07:49)
Absolutely. Santi this was fascinating. Appreciate you joining me today. I'm definitely going to try and roll this out in our team. I really want to start using this. I think it would create a lot less confusion and stuff as well as all our kind of marketing function grows and even just within product and engineering here. So thank you so much for joining me.
.webp)
