Why the hurry to launch an MVP?
Oct 7th, 2012 by Joca

I mentioned earlier that I was starting:

a new project called “The startup guide: how to create and manage profitable web products”. It’s a blog that will eventually become a book where I’ll explain how to create and manage a web product with a profit.

Well, I finished writing the book which is called “The Startup Guide: how startups and established companies can create and manage profitable web products“. The book is focused on how any type of company – no matter if it’s a startup or an established company – can create and profitably manage a web software. All it’s content is available at the “Guia da Startup” blog. It’s currently in Portuguese so it’s a good opportunity for you to practice reading in a new language. If you are not up-to-date with your Portuguese skills, there’s the option of using Google Translate but some meaning may be lost in translation. For these reason I intend to translate the content into English eventually.

One of the most popular posts from this blog is about the reasons to make fast the first version of your product. Why do we need to make an MVP? Why not wait to have the product with more features to launch it? Herb Kelleher, co-founder and former CEO of Southwest Airlines has a famous phrase to motivate people to do things:

“We have a ‘strategic plan.’ It’s called doing things.”

This “strategic plan” can be translated into the #jfdi hashtag which means something in the lines of “just focus and do it” or “just freakin’ do it” (polite form).

But why the hurry? Why can’t we keep working on our product until we feel comfortable it has all the features we believe are needed to solve the user’s problem?

Well, there are 3 main reasons:

Reason #1: The moment of truth!

The longer you take to put your product in front of real users, the longer you take to start getting feedback from real people to know if you’re on the right track. And what’s even worse, you’ll probably be giving too many steps in the wrong direction.

A software is supposed to solve a certain problem of its users. You will not know if you have built a good product until the product is used by real users and it actually solves one of their problems. The longer it takes for this to happen, the longer it will take for you to know if your product is or is not the solution for someone’s problem.

And if it is not, what should you do? Change, adapt and present it again to real users! The sooner you know that what you’re developing is not on track, the better, because you’ll have spent less time, energy and money moving into the wrong direction.

Reason #2: Featuritis

There’s a limit to the number of features an user can understand. When we present a software full of features to a potential user, instead of providing her with a possible solution to one of her problems, we may end up creating a new problem for her. Kathy Sierra, a well known software development and user experience instructor, designed the Featuritis Curve that illustrates in a clear and fun way how user satisfaction diminishes as we increase the number of features of a product.

Reason #3: ROI

The longer you take to put your product in front of real users, the longer it will take for you get some revenue and the longer you’ll have to invest from your own money or investor’s money. Below is a typical return on investment chart. While you don’t launch your product and don’t have revenue, all you’ll have are costs, i.e., you’ll be in the investment phase of the curve below. This situation will only change when you get some revenue and this revenue pays your monthly costs. This is the monthly profitability phase in the chart. Only after a few months in the monthly profitability phase you’ll be able to get to the return on investment phase. It’s a long way:

Now take a look at the chart below. If you decide to delay your launch in 3 months, this can delay your return on investment in 6 months! Are the features that you intend to implement in those 3 months you are delaying the product launch worth the 6 months delay to get to the return on investment phase?

On the other hand, if you are able to launch 3 months sooner than what’s described in the first chart, you’ll get into the return on investment phase 6 months sooner. Isn’t that worth figuring out how to launch your product faster?

If you’re not embarrassed…

There is a famous quote by Reid Hoffman, founder of LinkedIn, which really resonates with the MVP concept:

“If you are not embarrassed by the first version of your product, you’ve launched too late.”

To illustrate this quote, here are some print screens of early versions of well known software products:

Google in 1998

Twitter in 2006

Linkedin in 2005

Facebook login screen in 2005

Facebook in 2005

Next post

Last year I decided to run a lean startup experiment. Would it be possible to build a software and market it without using Locaweb’s marketing power? The result of this experiment is a calorie counter web product with more than 17,000 registered users in less than one year of operation. In my next post I’ll explain how I built the first version of this product in 10 days.

14 people like this post.

Restriction driven simplicity
Jan 20th, 2012 by Joca

I just returned from vacation and was reviewing some photos in my cel phone when I found some old photos from a previous trip to SF. In the airport there was an exhibition about TV sets and some old remote controls got my attention. Here’s a picture of them:

Old TV remote control

Old TV remote control

Checkout the number of buttons in the remote control. The maximum is 4. There are some remotes with only one button. When I was a kid I remember the first TV bought in my house with a remote control that had only 2 buttons, one for volume and other for changing channel. That simple! That was around 1975. At the time, the technology for making a remote control was too expansive, so it could not be too complicated and have too many buttons, otherwise it would be too expansive to be sold in the market. That was the restriction that drove the simplicity of those 1st generation remote control. Now we don’t have that restriction and we get remotes that can accomplish much more tasks but are way more complex. Take a look at the picture below (and I even picked a not-so-complex one!):

Digital TV Remote Control

Digital TV Remote Control

So maybe next time we want to design something more simple, we can think of imposing some restrictions to the design process! 🙂

4 people like this post.

Agile Product Discovery in a Non-Startup Environment – Building MVPs
Nov 29th, 2011 by Joca

As mentioned in my first post about Agile Product Discovery, I’m trying to take the ideas I used in my lean startup experiment (phase 1, phase 2 and phase 3) in a non-startup environment.

Locaweb has almost 700 employees now. We ended 2010 with approximately $100M in revenue. We have around 130 people in our engineering group which include software developers, system administrators, user experience designers and product managers. We decided to use the SaaS team – around 25 people – as the group who will be part of the experiment.

In phase 1 we worked on figuring out what to do. The next phase is building the MVPs!

Organizing the team

From the 10 ideas we tested, 6 had enough traction to motivate us to build the MVPs, i.e., the minimal viable product. However, one of them was not simple enough to be developed as an MVP in 1 week so we decided to move on with 5 MVPs. The self-organized into 5 groups of 5 people each to work on developing the 5 MVPs. We wanted the groups to have focus during a whole week, so the groups were allowed to work in a different place so they ware not disturbed by daily work. Since we could not leave the company without anyone capable to deal with daily needs of our existing SaaS products, we decided to have 2 teams working during one week and the other 3 teams working during the next week.

Building the MVP

Building the MVP

Building the MVP

Building the MVP

Building the MVP

Building the MVP

Building the MVP

Building the MVP

Building the MVP

Building the MVP

Building the MVP

Building the MVP

The MVPs

And with no further ado, here are the MVPs:

Lessons learned

  • It was good to have the teams fully focused for a whole week.
  • Since we put in the same team people who are not used to work together, it was a bit difficult to estimate the effort and many times we under estimated the effort.
  • In some products we believe we didn’t get the M for minimal correctly. We may have built sub-minimal viable products that may require another week to get to the minimal level.
  • Back to the daily activities of the non-startup environment it’s a bit difficult put some energy, even a small amount, to the MVPs.

Next steps

Now we are measuring the interest in each of the MVPs. We intend to have another Agile Product Discovery week in Feb/2012. During this week we intend not only to discover new products, but also work on the existing MVPs, specially those that we believe are sub-minimal.

3 people like this post.

Agile Product Discovery in a Non-Startup Environment
Sep 15th, 2011 by Joca

I mentioned here about my lean startup Experiment (phase 1 and phase 2). I’ll post an update on this topic soon.

Here I want to share another experiment I’m running. I’m trying to take the ideas I used in my lean startup experiment in a non-startup environment.

Locaweb has almost 700 employees now. We ended 2010 with approximately $100M in revenue. We have around 130 people in our engineering group which include software developers, system administrators, user experience designers and product managers. We decided to use the SaaS team – around 25 people – as the group who will be part of the experiment.

I presented to the group my lean startup experiment and proposed that we experimented doing the same.

So we now have 4 phases for the Agile Product Discovery:

  • Phase 1: figure out what to do
  • Phase 2: specify the product
  • Phase 3: implement the product
  • Phase 4: monitor the product performance

We decided to break phase 1 into 3 steps domes in 3 different days in small chunks of 3 hours each. However, we realized that it would be more beneficial to work on the 3 steps in one full day instead of breaking it into 3 separate sessions in different days.

Phase 1 – Step 1 – Product Ideas

First phase of the experiment was to brainstorm product ideas. We used 2.5 hours for this phase. We divided the group into 5 groups of 5 people each and the groups have to come up with product ideas or feature ideas for existing products. The only constraints were that the idea should be targeted to SMBs, the target segment for Locaweb. Should not be targeted to niche groups such as lawyers or medical doctors. Should be possible to develop an MVP (Minimal Viable Product) in 2 days with no interruptions.

Each group come up with 10+ ideas so we were able to generate a total of 50+ ideas. Each group had to filter the ideas down to 5. Then each group presented the ideas to the rest of the team, who made questions and decided what ideas to move to phase 2. At the end of the session we decided not to included any features of existing products, only new products should go to the next phase. We end up with 13 products in our list!

Phase 1 – Step 2 – What Is The Problem?

For phase 2 we got more 3 hours. During 2.5 hours the 25 people self organized to define for each product what was the problem that the product was solving, for the problem will be solved and why it is worth to solve this problem.

From the 13 products that came out from phase 1, we dropped 4 and kept 9.

Phase 1 – Step 3 – Creating Pages and Ads

In step 3 we created the pages using unbounce and the campaigns with Google AdWords.

Final remarks about phase 1

This is it for phase 1 – figuring out what to do.

It’s a bit harder to do product discovery in a non-startup environment. Even if you have full support from senior management, it’s difficult to get away from day-to-day tasks. For this reason, as I mentioned earlier, I suggest doing the phase 1 in a full day and not divided into 3 steps in different days as we did.

Other than that, the creative process from idea generation to single page plus ad implementation was quite fun and engaging. The team was really energized. 🙂

In future posts I’ll comment on the results of phase 1 and the work done in phases 2 and 3. Stay tuned!

6 people like this post.

Lean startup experiment, phase 2: building the MVP
Aug 24th, 2011 by Joca

My lean startup experiment is an experiment I’m running to see if it is possible to launch a successful product (product = customer facing software system) without spending too much money and in a short period of time.

Actually the name startup is a bit misleading because this process could and should be use not only by startups but by companies of any size. This process integrates quite well with Agile Software Development and with Continuous Delivery. For this reason, instead of lean startup, I prefer to call it agile product discovery.

Phase 1: idea funnel

I already mentioned about my lean startup validation experiment in a previous post. In the first phase I had 5 new product ideas and used unbounce to build a simple page describing the service and asking people to provide their email address if they wanted to be notified when the service. Then I setup a Google AdWords campaign for each product idea in order to generate traffic for the product pages.

Cost so far, $300 for each product test, total $1500.

The product with most interest was a calories log system where the user informs the food she ate during the day and the system calculates the total amount of calories, also informing how many of those calories were red (we should eat only 10% of red calories per day), yellow (up to 35% is ok) and green (at least 65%).

Phase 2: MVP – Minimal Viable Product

Ok, now that I have a product idea with potential demand, I should build an MVP (Minimal Viable Product) to better understand this demand. In order to do that, I need a logo, a visual design and a system.

For the logo, I decided to use a Brazilian service named We.Do.Logo, a crowd sourcing system where you describe why you need a logo and many designers present you with options. You get to interact with them and eventually you pick one. The name of the system is ContaCal. Conta means count in Portuguese. The winning logo is:

ContaCal logo

ContaCal logo

I paid $310 for the logo.

For the system, I decided to use a service called Startup DEV. With an agile style planning meeting plus 48 hours of coding, they deliver the MVP. I hired them, send them my wireframe:

I also selected a WordPress template from themeforest to be the guide for design. The cost of the template was $35 and the Startup DEV service cost $3K.

The result was great. The Startup DEV team did a great job and now I have an MVP to test. I’m still finishing the web site and will probably launch the service o during the next weekend. By launch I mean sending an email to all the people that showed interest during phase 1 and resuming the Google AdWords campaign.

But meanwhile I want to invite you to use ContaCal. The system was made in Portuguese and I still don’t have plans for an English version. Next steps will depend on demand. 🙂

To use ContaCal, please visit http://app.contacal.com.br.

Total cost and time so far: $5,025 – 3 weeks

  • Phase 1 (idea funnel): $1,600 – 2 weeks
    • 5 product ideas pages in unbounce: $50
    • 5 Google AdWords campaign: $1500
    • 5 Domain registration: $50
  • Phase 2 (MVP): $3,425 – 1 week
    • crowd sourced logo: $310
    • wordpress template: $35
    • wordpress template adjustments: $80
    • startup dev MVP development: $3000

Stay tuned for the next steps

  • website launch
  • online campaign (Google, Facebook, Orkut, etc.)
  • real users feedback!
5 people like this post.

Agile Product Discovery
Aug 21st, 2011 by Joca

I recently posted and twitted about my lean startup experiments.

The word startup in lean startup may be misleading because startup gives the idea of a new company creation. However, the concept on lean startup fits very well within established companies, no matter its size. I believe that instead of using the startup word, I’d rather name it as Agile Product Discovery, an iterative process of discovery of a problem and its best solution that can be turned into a product.

I’m reading now The Entrepreneur’s Guide to Customer Development: A cheat sheet to The Four Steps to the Epiphany:

The book’s cover is a cheat sheet by itself:

Here’s an excerpt of the book to give you motivation to read it all:

First, draw a map of your ecosystem.

  • The entities involved. Draw a box or a circle representing each entity in your ecosystem. Entities include users, customers, channel partners, technical partners, strategic partners, advertisers, your customers’ customers, etc. Include all entities that either provide value to you or receive value from your product. Value can be derived from money or the use of a product. Value can be direct (what a user receives from using a product) or indirect (money an advertiser gets from product user eventually).
  • Flow of currency. Draw lines or otherwise show your assumptions regarding the flow of currency. Who pays whom?
  • Product Distribution. Show your assumptions regarding how the product moves through channel(s) to reach end users.

Questions to consider:

  • Are you relying on third party technology that requires a formal partnership?
  • Are you relying on channel partners that will help you bring the product to end-users?
  • If you have a “free” business model and are looking to scale users, who will you eventually earn money from?
  • Are you partnering with a manufacturing firm?
  • Will you sell data or leads to third parties?
  • Does your product benefit your customers’ customers?

Second, define the value proposition for each player.
Each entity is only a member of the “ecosystem” if it will receive benefits by participating. For each member of the ecosystem, what benefit do they gain and what are they willing to trade in exchange? These value proposition statements will evolve into your core C-P-S (Customer-Problem-Solution) hypotheses that you test during Customer Discovery. For now, however, provide a concise description of the value you presume they will receive.


  • Users will be entertained
  • Advertisers get the attention of thousands of users
  • Buying influencer is happy to choose “green technology”
  • Customer’s customer gets highly qualified leads
  • Channel able to sell services on top of product
  • Customer will save money, mitigate risk, or increase market share

Third, posit a final MVP
As defined above, an MVP is “a product with the fewest number of features needed to achieve a specific objective, for which users are willing to ‘pay’ in some form of a scarce resource.” The reason the definition is somewhat obtuse is that we wish to differentiate between a “final” MVP and one or more intermediate MVPs. Final MVPs ostensibly test the business model. Intermediate MVPs test high risk components of the business model.

To develop assumptions regarding your final MVP, think of what you need to provide to each entity with whom you have a direct relationship in order to achieve the value you identified above. What are the basic features of the product each user requires to get the ecosystem functioning? What does each entity pay – whether money, attention, resources or some other currency? Describing what your final MVP looks like establishes an end point to the Customer Discovery process.

  • Currency = what the user/buyer “pays” for using the MVP
  • MVP Metric = what you are measuring to determine viability
  • Value Determinants = what the user/buyer requires (minimally) in order to spend their currency, such as features

Fourth, where’s the risk?
The goal for laying out a path for your Customer Development efforts is to prioritize and test your gating factors. If you validate key assumptions, you have proven critically important aspects of your business model. If you hit unexpected roadblocks and points of failure, then you have increased your odds of success by catching these issues early.

Think of critical near-term risks. Does your technology represent a significant risk? In other words, can you build what you believe the market needs? If your technology is difficult or costly to produce, what market-testable milestones can you build that would result in sufficient evidence to induce you to pivot or move forward? A proof of concept? A prototype? A demo?

If your risks are predominately marketing ones, what minimum set of features will result in paying customers? Or: What minimum set of features will result in a minimum of X number of users?

Time and money risks may affect intermediate MVP decisions. If your MVP will require $XM to build, but you only have $X/1000M, an intermediate MVP might be the answer to “what must I prove in order to acquire additional funding?”

Think of dependencies. If your final MVP requires that X happen, then can you build an intermediate MVP around X? What does X depend on? If possible, go to the root of the dependencies.

Fifth, create your Value Path
Your value path is the journey of Customer Discovery that takes you from where you are today to your proposed final MVP and includes both intermediate MVPs and core assumptions to be tested. From the risk table you created, map out the set of core assumptions you need to test for each identified gating factor. For each intermediate MVP, you will likely have a set of assumptions to test through direct customer interaction, in addition to a version of the product to build and test through usage.

1 person likes this post.

Lean startup experiment, phase 1: the idea funnel
Aug 7th, 2011 by Joca

Four weeks ago I started an experiment. I had 5 ideas of possible startups so I put together a simple page for each idea explaining how the service was supposed to work, how much it would cost and if the visitor has interest, she can inform her email address to receive news of the service. I’m not a web designer, so I needed help to put together a simple page for each startup idea I wanted to test. @dovb recommended a very good service named unbounce:

I defined a name for each startup idea and registered a domain for each one so each startup description page had its own URL.

I used Google AdWords to generate traffic:

I set $15 per day as the limit for each startup campaign. The startup description pages received a total of more than 2500 visits and more than 300 people shoed interest in the services described in these startup description pages. This hole experiment cost me $1500 including AdWords, unbound service and domain registration. $300 per each startup experiment. It could have cost even less since the interest (click through rate and sign up rate) was clear after the second week of the experiment.

Lessons learned

    Next time you have a startup idea, try running a startup validation experiment. It will certainly be cheaper than investing too much time and money in your idea and after launch realizing that there are no customers for your startup.

4 people like this post.

The good is the enemy of the good enough
Jan 3rd, 2011 by Joca

Everybody knows the phrase “the perfect is the enemy of the good” attributed to Voltaire. But sometimes even “good” is way too much for what is needed, i.e., “the good is the enemy of the good enough”.


The search for quality

The search for quality can go on forever because there’s always space for improvement. In software development we know this and that’s why we have agile methodologies, which have the terms “early and frequent delivery” in two of their principles:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

source: Principles behind the Agile Manifesto

There are other two quotations, from Coding Horror blog, that remind us why “the good is the enemy of the good enough”:

Version 1 sucks, but ship it anyway.

If you aren’t embarrassed by v1.0 you didn’t release it early enough.

Fast iterations give us rapid feedback, so we can correct course and make the software as close as possible to customer requirements

Lessons learned

  • Version 1 sucks, but ship it anyway.
  • If you aren’t embarrassed by v1.0 you didn’t release it early enough.
  • The good is the enemy of the good enough.
1 person likes this post.

How do we know what the customer wants?
Sep 12th, 2010 by Joca

In my last post I mentioned the lessons we can learn from the end of Google Wave and I also mentioned how important it is to know the customer, to understand if our product idea solves a customer’s problem and if the customer is willing to pay for this solution.

But how do we know what the customer wants? Ho do we know that our product actually solves a problem? How do we know if the customer will pay for this solution?

Going directly to the point: don’t ask!

Stop asking questions

Stop asking questions

Asking directly to the customer what she wants may not bring you good results. Do you remember that famous Henry Ford saying that if he asked what the customer whats, they would have answered “a faster horse”?…

There’s also Jakob Nielsen’s first usability law:

Don’t listen to the users.

What he says and what he really means

What he says and what he really means

What she says and what she really means

What she says and what she really means

This type of bold phrases, like don’t ask and don’t listen to the user remind us that even more important than listening to the users is truly understanding what they need.

Usability tests use this principle. In a usability test we ask the user to perform a certain task and we watch how the user does it and what problem she faces. If we asked the customer if the product is simple to use, good chances that the answer would not be 100% accurate.

Another good exercise is to watch an user 3 minutes before and 3 minutes after she uses a product. Chances are that she does something prior to use the product, and something right after finishing using the product that could be incorporated into the product facilitating its use. If we asked her what she normally does before and after using that product, maybe we wouldn’t get a good answer since the actions could be so automatic that she even realized she was doing something that could be incorporated into the product.

But what if we don’t have a product? Well, use a prototype! 🙂

Lessons learned

  • Just asking and listening to the customers is not enough to understand what the customer needs.
  • We have to get out of the building and go where the customer is, talk to her, watch her using the product in her “natural habitat”.
  • If we don’t have a product, we use a prototype.
Be the first to like.

Prototype: first impression
Aug 29th, 2010 by Joca

The word prototype is formed by two greek words, protos (first) + typos (impression). We know how important it is to use prototypes as a first impression of our products and systems, as suggested by the origin of the word.

If I can’t picture it, I can’t understand it

Albert Einstein

When we think about web systems prototypes, we normally imagine high fidelity prototypes or at least computer made prototypes which are interactive so they can be used in usability tests.

There are many tools to build prototypes:

However, before making a high fidelity interactive computer based prototype, we can draft this prototype. This draft will serve as a tool for very useful discussions about the product and its features. And to build this type of prototype there’s no better tools than pencil and paper. It’s cheap, fast and very easy to use!

I’ll finish this post with some examples of prototypes draw on paper, and they’ll give you an idea on how powerful they are.

2 people like this post.

»  Substance: WordPress   »  Style: Ahren Ahimsa