A key goal when you decide to start a new software project should be:
"What you need to do to acquire customers."
All software has customers. Whether it is an internal software for your company, a very complicated API, a very simple mobile app, or anything else. If you have already started developing the software, but you still don't know who your customers are and what their pains are, I suggest start trying to answer these questions as soon as possible. One of the major causes of software development failure is not having anyone that wants to use it.
Another good exercise is to consider yourself as the customer number Zero of your own project. Even if you are not a direct customer, will help a lot if you try to estabilish how the product you are developing can help you back.
As an example, these are the customers of my project LiveSource:
"Software developers (including programmers, managers, product owners and possibly you)"
There are several solutions I can offer to my customers, but I will not just assume I already know which one they are most interested in. Only after some customer interviews and prototype presentations I understood that "Improving Communication" is the subject that causes my customers' most intense reactions.
You can help LiveSource answering our online survey. Thanks!!
http://www.surveymonkey.com/s/63GQJYS
Acquiring the first customers is an iterative process. You usually start talking with people and sketching some kind of prototype. Then you come back and survey or interview your prospective customers, then you make adjustmets in your prototype and repeat the whole process again.
In some projects, this process can be quite fast, taking only a few days and you already have a very simple prototype that causes enthusiam in your customers.
In other projects, this process may take much longer, depending on your ability to listen to your customers, how much of their pain you can share and understand, and the capacity you have to simplify complex processes.
In the case of LiveSource, I have to admit that my ability to simplify problems is lacking. I started trying to offer a variety of solutions at the same time and couldn't stop many new ideas that come to my mind every week. Don't let this happen to you ...
While refining your prototype, start searching for your Early Adopters. Try to find as soon as possible someone that charitably would actually use your product. Ideally, this person should also obtain some value back. If you can't get anyone to test your product, think how much harder it will be to achieve real customers. Keep repeting the process of interviewing customers and refine your prototype until you find your early adopters. (This post from Seth's Blog can help)
In most cases, to acquire users you need your product not only to work but also to have personality . Know more at this Minimum Viable Personality post.
In most cases, to acquire users you need your product not only to work but also to have personality . Know more at this Minimum Viable Personality post.
The early adopters for LiveSource are some of my developer friends who have already confirmed they will help with my product. But we can't forget: family and friends are a help only in the begining, real customers are those who actually bring revenue to your company.
Before adding a bunch of features to your prototype, you need to define how your customers will use your product in the future, how your production environment is going to be.
For a large software project, define and build the production environment can cost a very big effort. However, postponing this solution is a mistake. Set how your customers are going to access your product and have a Launch Page working on this production environment. With a Launch Page, at least you can test your market, generate a contact list, validate your idea and confirm if people would register to use your product or not.
The production environment for LiveSource took me incredibly few months to be built. After a long time spent with testing and integrating the commercially available clouds, I finally own a good and flexible production environment, able to support a complex project like LiveSource, using both Amazon EC2 and Google App Engine clouds.
The most important is to begin to test your market as soon as possible. Even before, or at least at the same time you are building the prototype or the infrastructure for your product.
You can register yourself right now for LiveSource at:
http://golivesource.com
I could start adding a lot of features to this link, but to be Lean I need to detect which one has the highest value for my customers. And then simplify this functionality to the most and start getting feedback from my Early Adopters.
Doesn't matter how big and complex your product is, choose the feature that has proven the highest value to your customers and describe in one sentence the main part of this functionality. This is a good start on the definition of your Minimum Viable Product.
As an example, in LiveSource, "Improving Communication" is the subject that has greater value to my customers. So here is the definition of my Minimum Viable Product:
- LiveSource is a web Toolkit that loads the source code of your software and generates an easy to read version of it, understandable for the whole development team including by non-programmers.
I know that LiveSource goes beyond the definition above, but without any doubt, today I understand that focusing only on this very viable functionality and making it work perfectly is what helps me to get real customers as quickly and efficiently as possible.
Summarizing, before you start developing your software:
- "Unassume" your assumptions (Unassumer.com)
- Survey your customers and your market (SurveyMonkey.com)
- Identify your MVP (Excellent Video about MVP)
- Identify your MVP (Excellent Video about MVP)
- Provide a Launch Page (LaunchRock.com)
- Build your production environment
Adding more functionalities to your MVP without the end users already successfully use the existing features can be a total waste of time and money. In most cases it is indeed what happens.
Not finished yet!! :-) Follow the part 2 of this blog:
No comments:
Post a Comment