Menu
originally published: 2024-01-24 12:52:48
Perfect, perfect. OK, so let’s start with the journey from the proof of concept to development to launch of that idea. First, tell me about maybe help me define the difference between a proof of concept and an MVP.
Yeah, for sure. So this step can be a bit nebulous for some startup founders and of course not every startup is an exact cookie cutter of another one. But there is some things, some hallmarks, some signs and things to look for that really tell you where you are, maybe if you’re not sure, or tell you things that you should be looking for if you are there. So if you’re in a proof of concept, it’s usually an extremely manual process, very hands on, no automation whatsoever. Kind of workflows are all kind of set by you. There’s not much happening behind the scenes, whereas an MVP starts to incorporate things that allow for automation and scaling. So things that might help you grow. Now, that is just a whole bunch of words, but an example of this would be actually one of the startups that we’ve helped support. The way that they kind of approach their first version, actually, I’ll explain the problem they’re solving and then their proof of concept solution the problem they identified is that, unfortunately, in the car maintenance world, in the mechanic world and stuff like that. Women who are getting prices on getting their vehicle fixed or just getting advice are spoken down to or over quoted for work very commonly.
And that sucks. So that’s their problem. Their proof of concept solution was to basically make a hotline. They put a phone number of one of the founders on business cards and they advertised it and they got people to start engaging with it. They gave it to friends and family, they networked it, they gave it out, and that’s what helped them prove their concept. People started calling this hotline, people started getting active advice. Now to move that into an MVP, they said, okay, what’s that core value and how can we automate that? How can we incorporate a chatbot? How could we make it so people could book sessions and log calls and give more information? That’s the step two, right? So taking a non-automated process proven to a small market and bringing it to more people.
Okay, great. So what would you say? Let’s say are some of the common misconceptions or assumptions that a founder may make when they’re actually launching an MVP.
Founders are the best for this. They have their heads in the stars and I’m not immune to this. Everybody wants to dream big and that’s an important thing. But there’s loads of misconceptions tucked in there and there’s loads of excitement that causes these sometimes, right? So you see things like founders, when they’re starting to launch an MVP, they’ll occasionally add features that weren’t validated in their proof of concept. So they’ll glue things on that they think are nice. A lot of founders, it’s not necessarily a misconception, but an assumption or like a falling point is groupthink, right? These teams are with each other all the time and everybody aligns, right? Everybody wants to chase this excitement. So groupthink happens. But I guess an example for that is my first startup that I founded when I was in college. That was when Uber was cool back in 2014, and we wanted to be the Uber of home care services, which meant that our problem solution was our problem is people don’t have time to cut their lawn. They’re busy professionals. Solution have some completely random person crowdsourced come and cut your lawn when the real solution is knock on your neighbor’s door and say, “Hey, can you cut my lawn for a week while I’m gone?” and hand them $50 bucks. So you can over-engineer solutions for things that aren’t really problems.
That actually almost sounds like a TaskRabbit.
Yes.
Is that what it is today? And that’s not doing too badly these days.
Yeah. So TaskRabbit. Actually they moved in, actually after the acquisition by Ikea. They actually had a pretty strong focus in there. They geared in a smart way. We were such a green team that I’ll get into more in another one of these. But yeah, it’s interesting. So there’s a direction there, but I think they moved in the best way.
Okay, so when we’re transitioning to an MVP, you’re talking about earlier, about founders who have their heads in the sky, sometimes they’re in the sand, but they have this vision of what they want the product to eventually be. So how do you separate that vision for a product that will eventually be there for everyone? With creating an MVP that has an initial set of simple things at the very outset?
So the easiest way from because this is something that Northern Devs engages in very regularly. It’s how we help our clients the best, and it’s kind of how the ethos for some of our other tech kind of works. But the easiest way to kind of make sure you’re scoping an MVP properly is to kind of work from the end back. So if you start out with that core problem you’re solving and then start to glue on things that you need to build that MVP to solve that core problem, and having a really frank conversation with yourself at every time you step back explaining why that needs to be there. Because if it doesn’t need to be there, that’s fine, right? Because the head and the stars, the head in the sand, either one. Those cool ideas, as long as your MVP works, can come on as incredible value adds that thing. Wouldn’t it be nice if it could do X? Sure. That can be there, just not in the first version. We’ll get it out the door and then we’ll grow it. So that’s kind of the points there.
Okay, so I want to talk about a principle that Michael Siebel had talked about when it comes to MVPs. He said, “Hold your customers tightly. Hold the problem that you’re solving tightly, but hold your solution loosely”. So what are your thoughts on this?
I love that quote, actually, because it speaks to the efficiencies of a startup, right, and how they should make sure they’re moving. My thoughts on this are big old thumbs up. But more so, founders need to act on this and not just hear it and kind of sit on it. I think. Knowing your customers, of course, we want to not only know them, but we want to hold them very close. And that’s something I’ll actually speak on really directly to early founders, especially if we don’t have infinite marketing dollars and we have drip feeding, word of mouth marketing backing us right now. And we’re getting to that point of building that MVP and getting in a healthy position traction wise. Holding on to your customers, listening to them, and rewarding them for being those early adopters that took the plunge is crucial. And I have a little story I want to talk on on that. And then second part, hold the problem tightly as well. But I think while you can hold it tightly, also listen to make sure that you’re articulating the problem correctly. That’s very important because maybe your problem, you were adjacent to the problem, but then you figured out the solution that was nested in there or you figured out the problem is more directly this, that’s still fine, that’s still holding it tight.
Solution? Being that we’re creatives and we’re thinkers and we’re doers and we’re making all these things, maybe your customers can tell you, hey, you’re overcomplicating this. This is solving this problem way better for us. So just save yourself to hell and make it easier. So your solution needs to be malleable. So I entirely agree with that. And super quick on the customers tightly, which we’ll circle back, actually, which I’ll probably talk on again when you’re talking to those early customers. What I mean by rewarding them is when I started another startup called Delivery, it was a food delivery app for shopping centers and it was a fun little play. I started it when I was at Virgin when I was selling cell phones. And the early customers that we had were our faithfuls, always came back, always supported. So we asked them for this input. If you don’t take that step, people just feel like you’re a giant unknown blob, right. They just kind of see the logo on the wall and it doesn’t mean the same thing. So hold those customers close because they are what make you an MVP and grow.
Okay, perfect. Thank you. So everyone talks about this lean principle or kiss principle “keep-it-simple-stupid”. What is the importance of actually maintaining this kind of lean method throughout the MVP process? I’m sure it’s hard, especially later on in the later stages.
Yes. I guess this kind of folds back into those earlier thoughts of how we’re going to scope what’s important, how we grow. But the importance of maintaining it is even more crucial. What we’re focusing on when we say maintain is as you’re in that MVP process and you’re iterating, and whether you’re out the door before you’re out the door. I’m going to speak as if we haven’t launched yet. Just for the core of it actually the same startup, that home care services startup. We thought of every cool bell and whistle you could imagine, live driver tracking status updates when people were on their way to their destinations, people would be able to buy mulch from us as a company. And that all somehow found its way into the MVP. So it’s very easy to put all of these processes in because they’re cool, but remembering that if we work from the problem back, we can very easily see that, oh, my problem solution only has a journey of about three screens, right? I’m there to cut a lawn. They have to book a time and a day and that’s my problem solution. Okay, great. And they need a profile page for privacy, whatever.
But the point is that’s your core adding all those nice bells and whistles is of course possible, but we have to get the product out the door first.
How important is shipping the product quickly, though, from that perspective?
Oh, crucial, you got to go if you can get that version one tuned. I think even one of the quotes from earlier Hessey really speaks to it. It’s like be embarrassed by it. Put out something that works, kind of. And if it doesn’t work, you know why. Right. It’s great to get out there and just see what the market thinks because that’s the real data. Are people going to vote with their wallets? Yes or no? Right. And that’s going to be what tells you how you move forward.
Okay, so let me see here. What do we talk about? Oh, yes, data one of my favorite topics. So you and I spoke about this earlier and you indicated that you have to always read the data whether or not you’re transitioning from a POC to an MVP when you actually launch, but even after you launch. So how do you get, I guess, a founder to not only develop this process, but how do you make him really good at it?
Oh, that’s a fun one. So I think in terms of how we manage this data, Hessie, and how you look at because there’s in theory, an infinite number of data points you could look at in your startup. Right. But what matters the most? I’ll give an example and then fold it back because it’ll kind of pull in. One of the startups that we helped actually develop, we were on the founding team for it was called Quickly, and it was a microwarehousing and logistics company. And what their goal was is the problem they identified is people didn’t want to wait 30 minutes for things to get delivered to their house. Right. They were tired of UberEats’ aggressive fees or gig companies aggressive fees and how they kind of position themselves. So the solution was quickly. It was a micro warehousing place, so they would store product in little, basically garages and facilities around a city. And then when somebody ordered that food would come from one of those warehouses and be delivered within ten minutes, it was really cool. So you’d order and you’d see it before you remembered you ordered. But the point of all that is looking at the data is huge.
In the first version of the Quickly app that went live, we noticed that there was an abnormally large amount of people that never made it past the ad address screen. And we’re like, what is happening on here? There’s people just dropping off like flies. Deleting the app, right. It’s marketing dollars down the drain. Data is huge because you can learn that through our research and through looking at the analytics of what people were doing. There was a mandatory field called “address name” that was designed to store data, like writing. If you put in your home address, you’d label it Home. Right? If you put in your office address, you label it “office”. But people didn’t understand the purpose of that field, and they would be frustrated that they didn’t know what to put in that, and they would just delete the app. That was all. We had them for about 10 seconds and they were gone. So when you’re looking at data, look at how users are behaving on your app, look for screens that they’re leveraging, look for parts of their application that they’re using the most, because that can tell you what direction you should be going in next.
Right? You’re not going to forge ahead in a direction that nobody’s leveraging. Right. If there are screens or tools that people aren’t using, two thoughts should happen. One, why? Maybe we can make it better. That’s a consideration. We’ll do research on that. Or two, let’s focus on the thing that everybody’s leveraging and put more effort into the things people want. Right. So that’s the data, how you manage it. You make a cadence and you focus on the KPIs. You use your own metrics to determine what’s valuable, and then you base your analytics and your data off of that.
So how much of that is based on the user experience on the app versus actually focus groups or speaking to some of those users? Is that part of looking at the data?
Yeah. So you can have live usage data that you’re viewing that’s kind of nebulous it’s out there and you can have focus groups. It’s funny, during when we ran the Quickly focus groups, everybody didn’t have an issue there. But you only see some of those things in the wild. So that does chime into it. Hessie like having these focus groups, these channels and understanding, okay, what are these people saying? But people, no matter what you do, are always going to have a bias, are always going to be more alert in thinking when they’re in a room with you. So having those two channels, it is part of the data. But yeah, that’s kind of the core of it is it can be part of it. Of course we’d want to run those as much as we possibly can to collect the data, but there’s always going to be a bit of a bias.
Okay, so let’s talk about the environment that we live in right now. You guys are a software development shop, but as we know, it’s making it increasingly easier to actually develop applications. Everybody knows about the low code no code development environments, and this could pose some significant impacts when you’re actually building your product, especially when it comes to protecting IP. What do you think?
Well, the IP side of the coin in dev is a very powerful one, and so is low and no code. I won’t belabor this at all, but Northern Devs, we’re actually focusing on a platform that’s designed as a low code option, no code for founders that may not want full stack dev services. So we’re aware and we’re participating in that channel because we see the value in it as well in terms of that direction, in terms of how those dev environments work. The impacts in the MVP sphere, I think, will go very strongly towards these low code or no code solutions or even some proof of concepts can be in low no code. How does that impact IP? It’s tricky because a lot of the time, like we were talking about with Mr. Siebel earlier and stuff like that, getting a product out the door, getting exposure, and shipping something, doesn’t necessarily give us a lot of intellectual property rights. Right? Like if we built it on bubble or something like that. The IP for a lot of modern tech in plays, lives in algorithms, proprietary formulas, and tools that founders may leverage inside of those low no code apps.
I would say that the IP protection at the MVP sort of stage isn’t that strong in the low no code space outside of these algorithms or outside of these proprietary things that are being made. Right, okay. Yeah, it’s kind of the core of it. There is like, okay, if I have a special way to maybe, for example, something like back in the joby days when maybe we had a really specific way to predict the time it would take for somebody to cut lawns based on the square footage. And we can give a cool example of that. That’s cool, that’s IP-able. But the platforms itself are tricky to regulate in that space.
Okay, so I have one more question for you, because I think everybody is starting to see the value of this generative AI space. And it doesn’t really matter what side of the fence you’re on, whether or not you agree with it or not, and being able to unleash this thing in the public before it’s even ready. Okay, that’s my bias. I apologize. It does have impact on the future, and I would gather to say that it also has impact on developer jobs. What do you think about the future of development? Given the work that you’re doing and the fact that you’re actually on, I guess, the cusp of seeing some of this technology come to the forefront? What is your advice to founders and how do you think it’s going to evolve for them?
Oh, I think it’s crazy. So there’s a few channels that you can kind of play into this and I love. So, Hessie, your opinion in there is very valid. I think there’s considerations that we should have, but in terms of the future, it’s exciting because this is, in my opinion, one of the coolest exponential growths we’ve seen in a revolutionary tech, right? And it’s so powerful to see, oh, even between version three or version four of a specific one, there’s just world-changing differences. What does that mean for devs and for startups, though? So for devs right now, ChatGPT, sorry, AI models are really relegated to being assistants, right? For example, GitHub has a program called Copilot that can complete code and add flags and information to your code to assist you. Makes you more efficient. Right. So at this stage, it’s an efficiency improvement. At future stages, I will speculate and I’ll say it explicitly is speculation, but in the way, looking forward that if you have AI that’s trained off of your tech stack, that’s preexisting writing new features will still require human intervention, but they can be laid out, they can be prepared by AI.
Right? So the legwork or the really in-depth connecting logic can still be done by a human, and then eventually we’ll see it be even more taken over with a dev, kind of looking down and seeing what’s been done. What impact does that have on startups? What’s the actual application here? At this stage today, we’re not seeing a whole lot of crazy shifts from that because AI models are still pretty pricey. They’re expensive, and they’re hard to train for specific use cases. But going forward, I see them creating some pretty powerful efficiencies in how version ones are made, right? Because if you can have the framework created by an AI, that’s where a lot of your initial time lives. And if suddenly that part’s gone and we’re now working specifically on the logic or building the core problem solution with the dev talent, we can see things get even faster. Right? In terms of how founders will play into this, if you’re in a startup now, or if you’re coming up with an idea for one, don’t shoehorn AI in. Listen to your buyers and figure out how you can make it an integral part of it, because that’s going to be a new standard for how things start to move, right?
We expect that more human touch. We’re expecting that neural network touch that makes things more intuitive. So be ready.
That’s scary and yet exciting at the same time. I’m not sure if it’s more on one side than the other, but I think that we’ll leave it there. That’s all we have for today. And I’d like to thank you, Stephen McCabe, for helping me dissect this topic. Where can people find you?
People can find me on LinkedIn, just “Stephen McCabe”. If you hop over to our website, it’s northern-devs.ca, and you can find us there, feel free to drop us a line. We’re happy to connect and say hello.
Thank you so much. So, for our audience, if you have any topics that you want us to cover, please contact us at [email protected]. Just remember, we’re also accepting applications for our Incubator Investor Readiness Program, so please visit our website for details, altitudeaccelerator.ca, and we are also on podcasts, so look for Tech uncensored wherever you get your podcast. Until next time, I’m Hessie Jones. Please, everyone, have fun and stay safe.
Thank you.
This website uses cookies to save your preferences, and track popular pages. Cookies ensure we do not require visitors to register, login, or share any identity information.
