Finding the right fit for your engineering staff is important, and there's a few things to keep an eye out for on resumes to share here. Screening out bad fits is much more important than being sure to hire the perfect person. So screening out good candidates should be seen as a necessary mistake to ensure the wrong employees don't get hired.
Much of my focus is reducing the scope of MVPs and getting really essential. One method I want to explore here is what I'm calling reverse scoping. Instead of starting with all the hopes and wishes for a product, start with the time and money you have right here right now. What can you build with that, however small, to increase your commitment, increase the investment others have made, and build out something bigger.
We've built dozens of MVPs, some were brand launches at Google, some startups that raised $3M in funding, and some productivity tools we conceived that got acquired by bigger companies. Here's some of our hard won knowledge about building a product from the software perspective.
You're a white collar professional with over a decade of experience. You've found some major inefficiencies in your work, and repetitious tasks that you have to do, and not only you, but everyone in your role at other companies. If you're driven, creative and have an insight that's repeatable, you can leverage and sell it with software. This lets you stop trading time for money, and gives greater opportunity for growth. Hard work, no doubt, but worth a risk to escape the 9-5.
It's been a long time since maintaining your own servers was the best way to deploy a service. GCP and AWS are clear winners in the space. But like all good things, don't go overboard. There are many services you should steer clear of. You want to prevent vendor lock in so you can migrate to a competitor if need be. More importantly, there's often higher quality cheaper solutions if you can roll it on your own. This article gives a few examples of the tradeoffs.
MVPs are constantly changing to adapt to the market and needs of users. You have to be very judicious in your testing, so that you don't waste valuable cycles on things that will be thrown out soon after writing, or something that just lengthens development time beyond what the market can bear. You don't want to be crushed by a competitor because you were writing duplicate unit tests for your backend that will be rewritten in a month. That said, I'm going to go through the major types of testing, and when they'll be useful in your product lifecycle.
When hiring your first engineers, it's important to show them you have a plan for their success at your company. The best way to do this is to have a promotion pathway laid out for different levels of engineers at your company. Aligning individual contributor goals to broader organization goals ensures mission alignment and work is focused.
Doing a competitive analysis on your MVP and business idea yields many benefits. It helps identify gaps in the market, shows where the attention and money is focused, and may expose features that are extremely technically complex. It's a good thing to do before starting building your MVP to ensure you're hyperfocused on your unique value proposition.
With a functional app, you want to test before putting out to early adopters. Early adopters are going to be your biggest fans, so you want to get the experience as close to right as you can before launch. This is where usability testing comes in. Running a series of interviews with potential customers who haven't seen the app before is best.
When building an MVP, you want to steal as much code as possible. You're not worried about code licensing, you want to validate the market as quickly as possible with open source. So you want to use third party libraries to do the heavy lifting in your app. This is the heart of most great new companies, leveraging an emerging technology to serve a new market. Uber didn't build a GPS mapping system in its first version. Google didn't build an NLP system in its first version. Netflix didn't build a facial recognition library for identifying actors in its prototype. You shouldn't either. This article gives a few tips in identifying and using existing libraries for your MVP.