Build simple solutions to understand customer needs
We’ve all heard of the Lean Startup approach. Build fast, learn, and iterate. And building the MVP of LegUp’s platform was no exception. We went from early market tests to a product used by child care providers and families in less than three months. That journey is a story for another time, but you can appreciate at that speed it’s easy to go heads-down into the code. It’s tempting to obsess on the product more than the customer need that you’re addressing. That’s the problem I found our development team falling into.
We did early customer interviews. We codified our pre-product manual processes. I knew the broader problem we were solving up front. But as you build, how do you know if your design nailed the core value proposition? How do you tell how your MVP customers are actually using your tools — beyond what they tell you? Did our providers understand how to “go through the funnel” to post their open seats with us?
On the surface, this might seem more like a “big company” problem. But it was important for me to develop an engineering culture at LegUp that focuses on data-driven analysis and connects with the customer problems the business is solving. There are many complex solutions and technologies we could have considered. From my time at CarRentals I was familiar with several we could use. But our scale and use case starting out was simple. And I wanted to build something fast so that we could focus on quick iterations from our learnings.
Don’t build technology for technology’s sake. You need to know the business problem you are solving with any new technology choice.
I’ve always been a proponent that you shouldn’t only build technology for technology’s sake. Don’t get me wrong — we need to be intellectually curious and actively trying new technologies. But I also want my engineers to have a strong understanding of the business problem they are solving and how technology can help address it.
So for now, we built our own simple solution — named “Mina” after my childhood dog. It took half a day to get up and running and while it won’t scale when we get to millions of users, it solves our current need. It’s an “MVP to study our MVP” that forces our engineers to think about what successful usage of their features looks like.
Some of the questions that we’ve been able to answer include:
- What do “power users” look like? When do they tend to interact with our tools and what are the most common tasks they complete?
- How many users interact with messaging we put on the home page around new features? How many try them? Do they continue using them after a first look?
- How many people abandon more complex workflows before completing, and where do they fall out?
When you’re a small startup, it may not seem worth the effort to put an eventing system in place. But it doesn’t have to be hard. For us it was a few days well spent to better understand our product needs and shape our engineering culture!
Have you simplified your technology choices to deliver what the business needs? Let me know — I’m eager to hear your stories!