This is a guest post from Joca Torres. Joca is the director of product development and product management at Locaweb, Brazil’s leader in web hosting, cloud servers and SaaS applications like email marketing and online stores, serving more than 250,000 customers. His first startup experience was in the early 1990s when he founded and ran one of the first Brazilian ISPs. He has been working with internet related software ever since.
Joca is also the author of The Startup Guide: how startups and established companies can create and manage profitable web products. The book is in Portuguese, but Joca has been kind enough to translate a few sections of it for us. This is Joca’s third guest post in this series. Joca also posted all of the book’s content on the “Guia da Startup” blog (in Portuguese).
In my previous posts I explained the three reasons why we need to be fast in launching an MVP and told you how I built an MVP in 10 days. Now I want to explain the theory behind the practice. What do we need in order to produce high quality software in a hurry? Good methodologies? Good professionals?
Well, it’s quite difficult to argue against having great professionals as one of the key requirements for building good software. Ricardo D. Sanchez‘s latest post about the search of talent provides great advice on how to find good people but he also reminds us that “there is no doubt that hiring tech talent is one of the most difficult tasks for startups”. For this reason, we should outsource some of the tasks necessary to build an MVP.
The development of a web product is a multidisciplinary effort which requires knowledge from different areas:
To increase the chances of success of your product it is important that you know a bit of each of these areas. For sure you cannot be a big expert in all topics. However, the more you know, the better, so you can better manage the suppliers you’ll certainly hire to help you.
Two of these areas cannot be outsourced: product management and project management. Product management looks outside the building, discovering people with problems that need to be resolved, understanding what are these problems and how these problems can be transformed into a web product. The project management looks inside the building to ensure that all parts (software, website design, marketing, campaign, product, etc.) are in sync. It also cannot be outsourced.
What remains to be outsourced is software development, user experience, product marketing, system administration and the topic of the web product.
If you’re a good software developer, you can also do this part, reducing your costs. If you are an expert on the topic of your product you will not need help in this area. However, be careful with your decisions on what you’ll do yourself. Even though some tasks you can do yourself, it doesn’t mean you should do yourself. As seen in my previous post, outsourcing web site design cost me US$ 115.00. If I were a designer, maybe it was not worth spending my time doing the web site design myself in this initial phase of my web product, specially if we remember that an MVP is just an experiment.
I should also mention that, no matter how expert you become in product marketing and system administration, you will always incur costs in both areas. In product marketing, no matter how viral and social your application is, no matter how good your SEO is, you will always have some cost, at least in the beginning, to bring your first users. The most simple and affordable way to do this is via Google AdWords. In system administration, there are many tools that make the tasks of the system administrator much easier by automating most of the manual tasks and creating alerts for sensitive points of performance, but the infrastructure for this has costs, and learning to manage this cost is part of the system administration knowledge.
Having a great team and knowing what to outsource is good but not enough. Software development evolved and today we have many good methodologies to help deliver working software fast and with quality. I’ll explain briefly three practices that are mandatory in any software development which aims to be fast and produce quality results.
The first good practice that I want to comment here is the iterative software development. This form of development contrasts with the model of software development known as waterfall. In the waterfall process the software development stages are clearly defined and, once completed one phase and started the next one, we can not go back. We need to specify each and every feature we want in our product because software development is seen as a project with a beginning, a middle and an end that happens in sequence: requirement definition, detailing and specification of the software, coding, testing and production.
On the other hand, in the iterative software development, the same cycle is reduced to its smallest possible size and repeated several times using the feedback from the previous cycle to improve the next cycle.
Jeff Patton, a well known software development consultant, made a comparison between waterfall and iterative software development using an analogy with the process of painting a picture. Which of the following two processes seems to be more natural?
The iterative software development ended up being one of the pillars of the Manifesto for Agile Software Development written more than 10 years ago, that became a revolution in how software was developed:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
This manifesto considerably improved the way software is developed, ensuring greater involvement of the person who defines what will be the software during the development of this software.
From the manifesto some processes of software development have been created to enable this involvement. One of the recommendations that came as a result of the manifesto is that the teams that develop the software must meet periodically to define what to do and to track project progress. These meetings include not only software developers but also people that define “what” is the software and “how” this software is supposed to behave from the user perspective. “What” is defined by the function of product management and “how” is defined by the function of user experience. These regular meetings are essential to ensure the speed of delivery of the MVP.
Another very important good practice is TDD (Test Driven Development). This practice not only guarantees the quality of the software being developed, since by using this practice all functions should have tests – preferably automated – to ensure that what was developed is working as expected, but also increases safety for future software changes. When your software has tests, you can add new features and, through the tests, ensure that the software will continue behaving as expected in all situations envisaged and covered by the tests.
Having test coverage is essential to be able to run the third practice which I wanted to comment, continuous delivery. Continuous delivery of software means having the ability to deploy software in production at any time without hassle. You can only do this if:
Having continuous delivery is very important. After you launch your product and start receiving feedback from your users, continuous delivery will allow you to easily deploy the changes you’ve made based on the feedback from your new users.
Having good professionals, knowing what to outsource and using good software development practices is key to building software fast and with quality.
However, all this is useless if you don’t define precisely what is the minimum feature set required for your product. This is the primary responsibility of the product management function which, as I mentioned earlier, is one of the only functions that cannot be outsourced. Who has to do this is you.
At this point it is clear the importance of knowing the user and her problem. You’ll have to understand very well what this problem is and what is the minimal solution that will solve it for the user.
Be careful because with software we can do many cool things and can easily fall into the temptation to put “just this functionality” before launching the product. Think hard about whether this feature will not cost you too much development effort in terms of time, energy and money in exchange of the benefit it could bring to the user and the solution of her problem. Do you remember the return on investment charts from my previous post?
In order to build software fast and with quality we need:
In my next post you’ll probably remember David Cancel’s 2011 “Data Driven Business“. I’ll talk about what numbers I look at to understand the performance of ContaCal, my web product.
BUSINESS OF SOFTWARE – FOR PEOPLE BUILDING GREAT SOFTWARE BUSINESSES.
This year will be the 7th Business of Software Conference – 15-17th September 2014, Boston.
A three day conference for founders who want to build sustainable, profitable software businesses. BoS has always been a special conference for our delegates and we want to keep it special. Attendance is restricted to just 400 attendees in 2014. Registration open now.
This year we are also running Business of Software Conference Europe, 25-26th June. For more details, visit the dedicated BoS Europe site. Two days in the birthplace of computers – Cambridge, England.
Join our mailing list to be the first to know when this year’s talks go live and to hear the latest news from the conference.