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
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!
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!
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
And with no further ado, here are the MVPs:
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.
My lean startup validation 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.
In phase 1 I had 5 product ideas and wanted to know in which should I invest.
In phase 2 I pick the idea with more interest from phase 1 and invested in creating the MVP (Minimal Viable Product), ContaCal, a calorie counter system.
My phase 3 objectives were:
I officially launched ContaCal on Sep 4th sending an email to all existing users plus the people who showed some interested during phase 1.
I used Google and Facebook. Both generate leads, but Google generated 3 to 4 times more leads than Facebook for my specific web application. Today I’m running a $30/day campaign in AdWords ($1500/month) and I don’t increase it because ContaCal still doesn’t generate any revenue. As soon as I find a sustainable revenue source for ContaCal I’ll certainly increase this investment.
During a certain period my web site was out for maintenance and Google suspended my AdWords campaign. It took 8 days and many emails sent with one or two replies for Google to resume my campaign. This hurter my new user subscription rate.
I received tons of feedback. Some asking for additional features, some with difficulties in using the system and some thank me for the system!
Based on the feedback, I used some additional development as well as adjustments to the site layout. That costed me around $1000.
Below you can find some statistics about new users and how this number relates to certain events.
ContaCal users
Today was day 3 of Business of Software 2011, aka, #BoS2011. Checkout my notes on day 1 and day 2 if you haven’t done that yet.
Again good speakers and interesting topics, but again nothing really new for those who follow product management, agile software development and startup related feeds.
I guess the good thing of attending BoS is not exactly the content, that you can get through the net. It’s the opportunity to meet in person lots of people from the software industry and exchange experiences and opinions.
Below are some tweets and references. And again from the number of tweets it’s easy to spot the talks that brought me more new stuff.
You can find more at Product Principles blog: The Art of Asking
Paul Kenny (@PaulKennyOL)
You can find more at Product Principles blog: Creating a Data-driven Business
Dave Cancel (@dcancel)
Alexis Ohanian (@kn0thing)
And to end the conference, chinese grab-and-go food. My chines fortune cookie says: “You income will increase.” with that typo! It’s not saying “your income…”. It says “you income…”. I wonder what that means.
I suggested @SGBlank, @Cagan, @JurgenAppelo and Roy Singham, ThoughtWorks founder and chairman, as speakers for next year.
Now flying back home.
See you in #BoS2012.
Today was day 2 of Business of Software 2011, aka, #BoS2011. Checkout my notes on day 1 if you haven’t done that yet.
Beautiful day in Boston Seaport area
Full room at #BoS2011
One thing I noticed is that there are many people attending BoS who are from the old software model industry, the one based on licenses and on-premise installation. Good to see they are at BoS looking to understand that software is moving into hosted based subscription model.
You can find more at Product Principles blog: Engineering Your Marketing Outcomes
Patrick McKenzie (@patio11)
You can find more at Product Principles blog: Business of Social – What B2B and B2C Software Companies Need to Know About Social Media
Laura Fitton (@pistachio)
You can find more at Product Principles blog: Unleashing Creativity
Josh Linkner (@JoshLinkner)
Checkout this funny video about asking why. I purposely set the video to start at 6m20s so you can jump directly to the why joke:
You can find more at Product Principles blog: Praxeology – Lessons from a Lost Science
Rory Sutherland (@RorySutherland)
Checkout the IBM’s Wimbledon Lotus T5 campaign presented by Rory at the end of his talk:
Justin Goeres (@JustinGoeres)
You can find more at Product Principles blog: A Litany of Product Management Mistakes at FreshBooks
Michael McDerment (@MikeMcDerment)
First, you need to watch this video:
Obsessives: Soda Pop from CHOW.com on Vimeo.
You can find more at Product Principles blog: An Interview with John Nese
Peldi and John Nese
Today was day 1 of Business of Software 2011, aka, #BoS2011. This is my first time in this conference suggested to me by Dov Bigio (@dovb).
Good speakers and interesting topics, although nothing really new for those who follow product management, agile software development and startup related feeds.
Below are some tweets and references. From the number of tweets it’s easy to spot the talks that brought me something new.
You can find more at Product Principles blog: Highlights: Clay Christensen at Business of Software 2011
Clayton Christensen (@ClayChristensen)
You can find more at Product Principles blog: Naked Business – How Honesty Makes Money
Jason Cohen (@asmartbear)
Honesty
Alex Osterwalder (@business_design)
Business Model Canvas
You can find more at Product Principles blog: Building Bad-ass Software Businesses
Dharmesh Shah (@dharmesh)
You can find more at Product Principles blog: Pricing that Hot Saas
Jeff Lawson (@jeffiel)
Tobias Lütke (@tobi)
Some time ago Rafael Rosa (@rafaelrosafu) presented me the concept of lifestyle startup in opposition to the growth startup everybody knows.
Growth startups – or companies- are startups that have one main objective, accelerated growth so it can make founders, investors and shareholders substantially rich when the startup is acquired or make an IPO. When you are focused on accelerated revenue growth, all your actions are driven by this goal, which has top priority on top of all other matters, including products, customers, employees, suppliers, quality, etc. Normal product question you hear in this type of startup is “how do we make this product sell more faster?” or “can we create another product or add-on feature to charge some extra money from existing customers?”. In this type of startup you tend to have people passionate about money.
Lifestyle startups – or companies – are startups where revenue has the objective to sustain the company and it’s founders and employees lifestyle. As soon as this issue (company sustainability as well as founders and employees lifestyle sustainability) is solved, the company can have full focus on product, customer, employees, suppliers, quality, etc. Normal product question in this type of company is “how do we make a great product that solves real customers problems?”. In this type of startup you tend to have people passionate about the product.
Sometimes it can be difficult to identify what type the startup – or company – is, but normally a conversation with the founders or some key employees around the topic of company purpose and people’s passion have good potential to help you identify the type of startup you’re dealing with.
Moving the point of view from the startup founder to the customer, i.e., use your customer hat and think as a customer. What type of startup do you think would you, as the customer, prefer to solve your problems?
People who read my posts knows I like to make comparisons between business world and medical world:
So here goes another analogy using the medical world. Move again your point of view and suppose you are a patient who received the news that you have a certain issue that requires surgery. What doctor would you choose to do this surgery, one who’s primary purpose is to get rich with medical practice or one who is really passionate about medicine and about making other people’s life better? Again, sometimes is difficult to identify the type of doctor we are talking to, but normally the way she describes your case and how it could be solved will give you hints on what type of doctor she is.
Ok. So back to my original question: what type of entrepreneur are you?
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.
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:
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.
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!
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.
In step 3 we created the pages using unbounce and the campaigns with Google AdWords.
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.
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%).
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.
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. 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.
First, draw a map of your ecosystem.
Questions to consider:
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:
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.
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.
