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

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

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

The MVPs

And with no further ado, here are the MVPs:

• SocialEagle: social network monitoring tool.
• Sob.re: virtual business card.
• SMTP Service: authenticated SMTP service with reporting.
• Seja Avisado: notification widget.
• Mezu: SMS marketing tool.

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.

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!

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

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: $4,945 – 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,345 – 1 week
  • crowd sourced logo: $310
  • wordpress template: $35
  • startup dev MVP development: $3000

Stay tuned for the next steps

• website launch
• online campaign (Google, Facebook, Orkut, etc.)
• real users feedback!

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.

Examples:

• 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.

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.

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.

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

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 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.

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:

• Adobe Fireworks / Dreamweaver
• Axure
• Balsamiq
• Flash / Flex
• iRise Simulation
• Visio

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.

Mas como saber o que o cliente quer? Como saber se nossa idéia de produto resolve um problema? Como saber se ele está disposto a pagar por essa solução?

Bom, sendo bem direto: pare de perguntar!

Stop asking questions

Perguntar diretamente para o cliente o que ele quer pode não trazer bons resultados. Existe aquela frase famosa atribuída ao Henry Ford que se ele fosse perguntar o que os clientes querem, os clientes iam responder “um cavalo mais rápido”…

Existe também a primeira lei da usabilidade do Jakob Nielsen:

Não ouça os usuários.

What he says and what he really means

What she says and what she really means

Exageros à parte, o que frases como pare de perguntar e não ouça os usuário querem dizer é que mais importante do que ouvir o que o usuário ou cliente ou futuro cliente diz que quer é entender o que ele realmente precisa.

Os testes de usabilidade fazem uso desse conceito. Num teste de usabilidade é pedido que um usuário execute uma determinada tarefa com o produto e observa-se se o usuário consegue fazer essa tarefa e quais as dificuldades ele encontrou durante a execução. Se perguntássemos ao usuário se é fácil usar o produto para fazer a tarefa, as chances de a resposta não corresponder à realidade são grandes.

Outro exemplo interessante é assistir a um usuário 3 minutos antes e 3 minutos depois de ele fazer uso de nosso produto. É provável que ele tenha feito algo para se preparar para usar nosso produto ou algo logo após seu uso que indiquem alguma possibilidade de novo produto ou de nova funcionalidade. Se perguntássemos diretamente ao usuário o que ele faz antes e depois de usar o produto talvez não obtivéssemos uma resposta precisa pois as tarefas podem estar tão inseridas no cotidiano do usuário que nem seriam percebidas como oportunidades de melhoria.

Mas e se ainda não tivermos um produto? Simples, basta usarmos um protótipo!

Resumindo

• Só perguntar e ouvir o cliente não é o suficiente para para saber o que ele quer.
• Temos que sair do escritório e ir até o cliente, conversar com ele, assistir ele usando o produto em seu “habitat natural”.
• Se ainda não tivermos um produto para mostrar, devemos mostrar um protótipo.

]]>