Explain the business in details
Imagine that your innovative startup will make gloves that improve lacrosse skills. Gloves that you can control wirelessly, that’s why you need a mobile application, seem reasonable. The team of developers’ is doing what you asked for. They are building a mobile application with enormous buttons because you need to use the app when you are wearing gloves. During the whole development, they are constantly thinking about two things: why those buttons are so huge, and what the hell is lacrosse?!? Okay, they can google “lacrosse” but do you really want them to google it? What if you’re doing rocket science, would you like them to google that?
Explaining business can be a tough one, but also satisfying. In the world of software, there are two kinds of people: technical and non-technical. No matter which group you belong to, you either talked with someone from the other or you must have heard conversations between people from both groups. These conversations can be very satisfying when interlocutors finish on the same page, or very frustrating when it seems both speak different languages.
I would compare “explaining the business” to explaining what “tech debt" is, both are hard to understand, but both are extremely important to be understood by both sides. That’s why it’s very important to assume that whoever is doing some software, might not have a clue about the business, so you must tell them about every single thing. Even if something is trivial to you, it doesn’t have to be for them. Maybe if you explained to them gloves and lacrosse, they would suggest controlling the app with a voice or gestures…. “Wait, what?!? We can control the app with voice or gesture? Then we don’t need those buttons to be enormous!!!” If you’re doing something similar to what’s on the market, i.e. e-commerce or providing some services, they might have at least common knowledge about something, but it’s not the same, not something they should base their opinion on, assume something about users, they need to learn it from you.
Define what you would like to test with an MVP
Setting a deadline is always a good idea, because it’s a perfect tool for defining the scope of an MVP and sticking to it. A deadline doesn’t always have to be a time, it can be a list of things that need to be done. Ideally, we should combine them because of the correlation.
Let’s assume that in the beginning, we have decided that we need to have those 10 things and our estimation is that 3 months are needed to deliver. During planning, we determined that we have 8 must-have features and 2 that are really nice to have, and if we can fit them within 3 months of development, we want them, otherwise we can postpone them. After 2.5 months, we can do a checkpoint meeting and see at what stage we are and make the final decision if those 2 features are going to be included in an MVP or not. A similar situation is when after 2.5 months someone has a brilliant idea of adding another feature. Then, our deadline works as a “safety word”. We don’t want to cross the deadline, so if that new thing is a must-have, we either have to resign from something else, or stick to the original plan and schedule a new thing post MVP. The truth is that before launch, we never can be certain that something is a must-have or not, and not having them, doesn’t mean we will deliver a bad MVP, because what differentiate software from hardware is this:
software is software, and software can be updated
That’s why before development starts, the question you should be asking is “What can be done within X months?” and not “How long will it take?”.
Ignore edge cases
It doesn’t matter how good your UX is or how well-tested your product will be, because life continuously validates that. What you think is obvious, it doesn’t have to be for real users and those users might not seek bugs, but just the number will always increase the variance, in short, there are no 100% crash-free systems. That’s why, you have to learn how to live with bugs in the products, you simply cannot avoid them. Having bugs doesn’t mean the product is bad.
Edge cases are edge cases because they don’t happen too often, otherwise they would be critical bugs. That’s why you always have to look at the scale, assuming that some issue happens to 1% of users, then, if you have a hundred users statistically, it will happen to only a single user, if you have ten times more, the number grows ten times. Sweet math. Thousands of active users is a pretty lovely number to start with, the number that can indicate your startup doing good, but also the number that tells ten of your users facing that edge case, or maybe they are facing ten different edge cases. So what should we do with them?
First and most important, we have to track them and I mean both bugs and users. Crash reporting is worth a day of delay, well it shouldn’t be the last implemented thing, but it shouldn’t be something you save time on. Okay, coming back to bugs and users. With bugs it’s simple: create a ticket, prioritize it and when the time comes, fix it. With users, you have 2 options: you can try to reach them, maybe you have their phone number or email, so you can try directly, you can send generic information about some issue, if it’s more crucial, how to proceed. No one will laugh at you, or no one will leave the product, because you told them that there was an issue, you are aware of this and you will try to fix it.
Work closely with the team or leave decisions to them
Taking responsibility for making decisions is never easy, especially when there are a lot of unknowns. You never know if the decision you make will be correct or not, and the wrong one might be a true game changer for the product.
But there is something worse than making a wrong decision, which is not making the decision at all. Often this is a Client's responsibility, because it’s his/her child, so he/she should have the last word. Unfortunately, it’s not always this way. There is a plenty of ways why this can go wrong, where most common are:
- Lack of time and unavailability, because of timezone difference, because of other responsibilities, other businesses, or private stuff.
- Miscommunication, because of a language or an accent barrier, because of the tool used to communicate
- Incomprehension, because one side doesn’t understand the other side's motivation, the way any side describes technical things or business things
- Fear of making the wrong decision
- Lack of knowledge or experience to make the decision
The most important thing to understand is that there is nothing wrong if you no longer can make decisions. You just have to admit it, leave making decisions to someone else, and stay involved as much as possible or as much as you want to. That’s the point when you have to trust the people you hired. This should be easy, because you already trusted them by hiring them. You did this believing they are smart, they did things, different things, so the gut feeling will help them make decisions.
It is worth noting that the decision can always be postponed, hoping that later there will be more context, but it’s important that both sides, Client and Developers, are aware of this and both sides are okay with the potential consequences of not making the decision right now, because there might be conflicts with other things. Sometimes this can be a blessing, because most of the time this means it was done a “simpler way”.
Do not invent the wheel again
There is a set of features in products that are implemented in all or nearly all of them, particularly in startups with a relatively small scope, and some features are very common, such as authorization, notifications, or payments. You have to choose one of the two ways as to how to add this to your product: implement it from scratch or use a 3rd party provider. Both approaches have their pros and cons, but in general, I think that for startups using already existing tools, it is a better way. Let’s assume that your product will have all previously mentioned features and that we count the time needed for implementation on both the backend and frontend sides.
Starting with authorization, there are different functionality needed, so it can be more or less complex but doing it on both sides will probably take roughly a month of work. Similarly, with notifications, maybe slightly less than authorization, let's say 3 weeks. Finally payments, everything from scratch? I would be super happy to see it ready sooner than the previous two features combined. We have an estimation of 4-5 months of development, depending on how many bugs will be implemented, it can take longer. And this time cannot be simply divided by 2 because, there is more work on the backend side, those are features hard to work on simultaneously on both sides, let’s say an overall timeline of 3 months. But wait, there are other things to do besides authorization, notifications, or payments.
What if the whole product could be done in those 3 months? That’s why we want to use 3rd party providers. That can reduce the time needed for authorization to, let say, up to 2 weeks, notifications in around a week, and payments probably in a few weeks, depending on the transfer flow. Which gives us 1,5-2 months, so the overall timeline of a month, not bad. Don’t forget that others already use these successful tools, they are somewhat stable and free of bugs your developers implemented.
The biggest cons of using existing tools are that they are not free, well sometimes they are free, but in general, they will take a piece of your cake, but it’s much better to give a piece of cake you actually have, rather than pay for thousands of potential cakes which you may never have. Don’t build a bakery when you sell 5 cakes a month, when you can outsource it. When commission becomes relevant, that’s the time for building a bakery.
Have you seen the first part of the Top 5 things you’ve been doing wrong your whole MVP?
Maybe you’re seeking a partner in designing and building MVP or other products? Let us know! Meanwhile, you can check out Why partnering with a software house is the right decision!
