Written in India inspired during our software planning for 2017.
I’ve built 3 SaaS products.
They’re very different to build, but a few things remain the same. Doesn’t matter what technology you’re using or what stack you building it with. There’s some solid things to do that will mean you’re building the right product, as quickly as possible, so you can start getting revenue.
Doing things wrong is my best learning curve. It means second time round, I do things a little better and the third time, I establish a pattern – a process and a model to do things the correct way.
Here’s my model for creating a Minimum Viable Product (MVP).
What to build?
Deciding on the right things to build can be, by far, one of the hardest decisions. Usually ideas come from an experience you’ve had where you’re not doing things as quickly or easily as you could be.
I find the best ideas come from ways to simplify things you’re currently doing.
The idea is to save you time and/or make you money. This is how ideas are born. You first find a need for something because you or someone you’re working with (a client, colleague etc.) are experiencing a pain point.
Pain points are awesome. It means there’s an opportunity. If there’s no pain point, the likelihood is your idea ain’t gonna fly.
If you are experiencing a pain point, your next step is to qualify if it’s just you or if this problem is consistent in other peoples lives too?
Here’s some of the pain points I had, and was the starting point for our 3 SaaS products.
Problem: “I was using an excel spreadsheet and searching on Google for contacts of Marketing Managers in the UK. I’d then try and find their email address to send an email to them.”
Solution: I developed Found.ly to automate the list building of targeted contacts, find their email addresses and then send them a personalized introduction email.
The solution replaces a manual, cumbersome process. But more importantly, guess what. We found it wasn’t just us with this problem. Thousands of people were doing the exact same manual process.
Problem: “My Digital Agency had clients that were looking for more ways to identify their website visitors. They were not happy with so much ambiguity on their website visitors.”
Solution: We developed technology that identifies the businesses based on their IP address. It turns anonymous data into actionable company names.
Customers wanted this tool straight away. There was a blur, an unknown that needed an idea to bring clarity to it.
Problem: “I’m not getting many responses on my emails. I don’t know why. Do you think I should chase it up with another email?”
Solution: I built a tool that sits on top of Gmail. With the same effort as sending one email, the tool attaches personalized, followup emails to the first one.
It’s massively time-saving and makes things easier than manually following up on emails.
Slowly things get easier each time that you do things wrong. Here’s what I learnt about what technology to select when you’re trying to build your MVP.
#1 First time. “Programming Language X is the one. It’s the most widely supported, it’s the fastest to build and most widely supported community.”
Sound familiar? Developers love advocating their preferred technology as the best. In some circumstances it is. In others it’s not.”
# Second time. “Programming Language X isn’t as good as I thought. There’s problems with concurrency and I can’t find other developers to develop on legacy code.
#Third time. “There is no best technology. Only best practices.”
After the third attempt, I’ve realised there isn’t (necessarily) a best technology to use for your product. It’s much more important to focus on best practices of developing software than what technology you’re going to use.
I recommend starting with the technology that allows you to build your product as quickly as possible to test the market. Tools such as Ruby on Rails, Python and .NET have predefined libraries and a scalable MVC structure to build things more quickly. Consider MVC as building blocks to create a house, instead of starting with a pile of sand only (I hope this analogy works!).
Proof of concept is key. Remember, Twitter was built in Ruby on Rails for years until they decided to redevelop in another technology. They chose the fastest path.
How to nail it?
Deciding on the right features to build is by far the hardest decision to make.
Running a startup is chaos (to begin with). Distractions come from all angles. From your own ideas, customer feedback, the dreaded bugs, competitor features. These inputs are constant. They are hard to deal with. It’s frustrating because in this chaotic mix, is your perfect product. It has product-market fit and shines above all other products.
How do you build your perfect MVP product with all of this noise? Come to terms with this one simple rule. You’ll never avoid these distractions, but you can learn to live with them and learn to focus. Learn to embrace imperfection (when you need to continue working on a feature vs. when it should be pushed live. Fix the top bugs, not all.
Managing peoples time
Feels like you could always do with more developers, right? No matter if you’re bootstrapped, funded or a solopreneur, it always feels your development needs to move faster. It seems like it will end, but it never does.
There’s always a backlog of features to research, qualify, test and launch. And in this big chaotic mix of inputs you need to try move fast. So, means more developers, right? Wrong.
The problems start early in your product development. It goes back to deploying the best software development practices to ensure everyone is aligned as a team, that you have a clear way of managing new ideas, features and bugs.
Have a quick search online for Kanban. It’s a process that’s helped us align our development team to have clear digestable ‘sprints’ (product development periods).
Here’s a few more tips.
1. You need to understand how to run small and incremental experiments and make the development of an MVP iterative, not pre-spec everything and develop a completely overhauled product.
2. Launch small, launch fast and let users dictate the priority and the significance of your product features.
3. Early stage users are your advocates, your experimenters and your advisors of your MVP. You need to launch something fast and allow customers to feedback and shape the tool. Make your MVP iterative and generate feedback, not aim for a perfect product for launch. It feels counter-productive, but trust me, it’s not.
My final point. Think about it. There’s a critical path in how you can create a product. You can do all the market research and planning that you want, but the best way is to let your customer pull your product in the correct direction, around a structure that you’ve created.
I’ve been writing this post while in planning our new features in India with team.
Here’s my SaaS products. We’ve got a great team working hard to make these even more awesome and I’m sharing the entire journey along the way.
Any questions or comments, give me a nudge and I’ll be there to answer them.
We’ll be releasing a new post regularly on Startup Life. To get each post as soon as I write it, sign up to the $10 mil mailing list.