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:
- software development: well, to develop a web product we need to develop a software, since a web product is a software, duh!
- user experience: we build a product to solve someone’s problem. The experience this “someone” will have when using our product must be good, very good, so this “someone” enjoys the experience and recommends our product to her friends. There’s an area of knowledge dedicated to this topic which is called User Experience or UX. It’s not limited to making our product look beautiful. It is also concerned with the interaction flow, to make it as simple and easy as possible in order to create a good experience for our users.
- product marketing: this is the knowledge required to find the people with the problem that your product solves and telling those people how your product can solve their problem.
- system administration: once the first version of the software is developed you need to deploy it somewhere in the internet so users can access and use it and it must be managed, i.e., it must be monitored to check if it is running with acceptable performance. If it is not running or is running but with poor performance, we need to fix it! This is system administration. You also need to backup the system data periodically, verify how much the database is growing, define a scale strategy. This is system administration as well. Does the application send a welcome email? Does it send other emails when certain events happen? How these emails are sent? The server you use to host the application and send emails has limits? You need to monitor these limits and define how to react in case these limits are reached. These are also system administration tasks.
- product domain expertise: your web product will have a certain topic. Online sale of physical goods, nutritional education, access and operation of bank accounts, email marketing, fashion are some examples of topics of web products. These topics require a specific knowledge different from all others listed above.
- product management: this is the knowledge needed to find people with problems that can be solved by means of a web product, to understand what are these problems and how these problems will be transformed into a web product.
- project management: knowledge needed to coordinate different activities done by different people that should culminate in a single result.
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.
What can and should be outsourced?
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.
Software engineering good practices
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.
Iterative software development
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?
Waterfall
Iterative development
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.
TDD
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.
Continuous delivery
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:
- you have test coverage to ensure that the software that you put into production is doing what is expected and;
- you have an easy and fast way to rollback your deployment if you happen to have any problems with the software you just put in production, you can restore the previous version of your software back.
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.
The importance of knowing the client and their problem
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?
Summary
In order to build software fast and with quality we need:
- Good professionals: in order to build good software we need good professionals. Is that simple. And Ricardo’s post is a great piece of advice on how to find good professionals.
- Outsource: we cannot do it all. We need to outsource part of the work required to build the software. It’s important to know what can and what cannot be outsourced.
- Good software development practices: software development evolved and today we have many good practices to help deliver working software fast and with quality.
- Know what to do: all the above is useless if we don’t define a minimal product that makes sense to the user, that actually solves a problem for the user.
Next steps
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.