How to communicate your MVP to the development team
You may have come up with the greatest idea of the century which will bring you bags of money (or just save the world in general) and afford you the freedom to finally make your own, independent decisions. This is absolutely fantastic but as you have already guessed it is not enough. There is hardly anything more common than a great plan that never materialized. The shipwrecks of half baked attempts abound in the sea of entrepreneurship. As an exercise try to count the domains that you have bought over the years and compare them to the ideas that made it to actual projects.
Turning an idea to a piece of software requires two skills. Both are relatively easy to pick up and are useful under any circumstances that you need to interface with a technical team:
Learn to scope your project:
Before discussing the scoping of a project I would like to ask you to dig up your developer hat. We need to pick the brain of a software engineer and understand how she thinks. Great developers are geeks obsessed with their craft. They are engineers who love to create. Their ideal situation is when they can generate truly useful (or just impressive) tools with elegant code. Left to their own devices, engineers will create, or at least aim for, projects like Zaha Hadid’s Vienna University library with walls sloping at 35 degrees.
It is a stunning building and one would have to consider the technical difficulty and cost behind such a feat. If the budget was no issue, then this looks like an engineer’s dream come true.
Something similar happens with software projects. Engineers have all these fantastic ideas and tools which they are dying to put to use.
Remove the developer hat for a moment and go back to your business persona. Left unchecked, you would probably also aim for the most feature-rich product possible. In fact, you and the software engineer, are creating a disaster; an accident waiting to happen. An over-ambitious project that requires infinite resources.
Back to reality
Truth is that nobody has an infinite amount of money or time. All our endeavors are constrained by the resources available. Time and money are top of my list, but I would also consider motivation and intellect. Your aim should be to identify what are the basic elements that without them the project would not be your project: Define the M in MVP. Your project should be ambitious but it should also be realistic and confined within the means available. Since we are using architecture for illustrating concepts, here is a design that I believe captures better the spirit:
The above building still looks impressive but it is also down to earth, has clear boundaries and it looks like it still gets the job done. Both buildings are libraries, both are functional, yet it is clear which one is the most impressive and also most expensive.
How to build the wall
Applications can always be improved and augmented. The demand for new features is endless, both from the business and the technical perspective. I have yet to see a piece of software that is still being used and all parties involved have agreed that it does not require further development. The only reason for stopping development or maintenance — which is also low pace development - is the death of a project. This fact, the bottomless appetite for more features, should be recognized as a dangerous pitfall for a new project.
You don’t have the luxury of endless development. You therefore have to limit your application’s scope. You should look into building a fence that determines the boundaries of what you want to achieve. The scoping of the project will help you to plan and dedicate resources to where it matters the most.
There are two steps for determining the limits of your system:
- Which are the user types? Identify the key players. In most systems, there are at least two types: the admins and the regular users.
- How are the users interacting with the application? List all the activities that each user category will be doing within the application. (call each activity a high-level use case)
Once you have the high-level use cases you have already established a perimeter of your application. The list of use cases can be further refined so that only the essential ones remain. Remember that this is an MVP (Minimum …).
The previous process, formally known as requirements elicitation, is complex and requires lots of expertise to get right. Your goal is not to reach a high level of detail, but to describe in broad strokes what is the basic functionality of the application.
Learn to communicate with the developer
The second step in creating the MVP is interfacing with the developers. There is no clear boundary between requirements and development. In fact, experienced developers will normally participate in the process of defining the application requirements, and requirements will change frequently during development. Even if this is the case, it is reasonable to be able to prepare some of the work before reaching the developer. This is a great way to get a head start and minimize any uncertainty with respect to the direction of the project. A list of use cases is an excellent first step toward effectively communicating your needs to the developer. As an extra bonus, having a list of requirements will allow the developers to jump faster to building the project rather than spend time discussing vague ideas.
Not all use cases are born equal
Use cases translate to features. For example, entering a user’s personal details translates to a ‘form’ with fields. The developer will interpret your request for data entry as an HTML form. Is this an expensive or a not so expensive feature? You would expect that in most technologies putting together a form is rather straightforward. A form with a few fields, like first name and last name, is rather simple.
Both yourself and your developer have a clear understanding that a form is easy. You want though to stand out from the competition so you realize that you are not too certain of the fields that you would like to record for the user. Let’s use as an example an application that stores data on entertainers (singers, dancers, stand-up comedians, actors e.t.c). Each entertainer has unique talents (singing ability, acting, trapeze skills ) and each one of these skills may need a different description. You may even want to record short videos or audio for each user. Using as guide your experience from earlier you contact your developer and explain that the form needs to have a few more fields, but not for all users. This is starting to get more complex and complex usually means expensive. At this point, it is crucial that technical people and business people can see eye-to-eye.
The developer needs to understand your need and should explain that this is getting complicated, e.g. time-consuming and therefore expensive. From the business perspective, it has to be clear that this is not an essential feature, at least initially, and that time should not be wasted on implementing a fancy feature that can be completed later (not at the MVP stage). A good compromise may be that a free text field is introduced to store relevant information. This is the type of compromise that should be reached after communication between the developers and the business owner.
The alternative would have been to set the developer down a long and pointless path and allocate resources in the wrong area. In other words, spend money without getting a result that suits the MVP.
The ability to quickly and effectively communicate with the developers cannot be overstressed. Good communication skills are not a ‘nice-to-have’ feature. They are essential ammunition in the armory and in many cases are even more important than technical skills. If a developer is not familiar with a particular technology, then it is only a matter of time for her to gain the knowledge. Poor communication skills, on the other hand, are difficult to improve in general and near impossible to acquire in the short timeframe of an MVP.
