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:
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!
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.
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.
Here’s a brief definition of a project:
A project is an endeavor with a clear definition of what needs to be delivered and the date when it needs to be delivered.
At first sight it may seem that a product is a project, but it is not!
A product is not a project because:
A product needs a more adaptable and continuous development process than traditional projects normally deliver. Agile Software Development, Lean Software Development and Continuous Delivery are process that present these characteristics.
Agile software development is a group of software development methodologies based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams.
Source: Wikipedia
Lean software development is a translation of Lean manufacturing and Lean IT principles and practices to the software development domain. Adapted from the Toyota Production System, a pro-lean subculture is emerging from within the Agile community.
Continuous Delivery aims to make software production-ready throughout its lifecycle, so that potentially every good build can be released into production and run effectively. The goal is to “…Minimise the cycle time from idea to delivery, and allow that cycle to be repeated frequently and reliably.”
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.
I’m reading a very interesting book entitled “The new rules of marketing and PR: How to Use News Releases, Blogs, Podcasting, Viral Marketing and Online Media to Reach Buyers Directly“:
I’m still reading it but its central idea is so simple and powerful that I wanted to share it here prior to finishing the book.
In the book, marketing is defined as the act of telling the world about your product, service, idea, art, belief, etc. to potential customers, volunteers, voters, followers, fans, etc. And public relations (PR) is the act of making the media talk about you and what you want to tell the world.
Marketing is usually done primarily thorough advertisement in TV, newspaper, magazines and any other available media. PR is usually done sending press releases to journalists expecting to see a note in mainstream media.
People want to get more informed prior to any commitment to a purchase or an engagement with a cause or pursuing a new hobby or… People now have access to the internet and can search information. We normally buy or engage with who give us good information. Even journalists don’t wait for new information to come to them, they go after the information on the web the same way potential customers do, searching the web. And the journalism itself changed, since there’s much more than just the mainstream media as possible source of news and opinions.
And here are the new rules of marketing and PR as described in the book:
Some of today big companies offer their services for free (Google, Facebook, Twitter, Linkedin, Slideshare, Youtube, etc.). They generate revenue through ads, having a paid version with more features or offering paid add-ons to users of the free product. This is known as freemium.
In order to benefit from offering a free version, your product must benefit from having a huge user base because of at least one of the reasons below:
So before going freemium you need to understand why you are offering a free service. Then you need to figure out…
After you figured out why you intend to offer to free service, you need to know how to generate some revenue because offering a free product will cost you money. All of the companies cited here had to figure out how to make money from their huge user bases. Here are some ways they used to generate their revenue:
Tip: If you decide to go freemium, don’t forget that you can only offer a free product if your marginal cost of adding another user to the product user base is as close to zero as possible, otherwise it won’t be a sustainable product and your urge for revenue may kill your freemium product.
Freemium is a viable business model but before offering a freemium product, you need to figure out:
DDD (Domain Driven Design) has a very powerful concept, so powerful that it is the first concept presented to anyone who is initiated in DDD, Ubiquitous Language:
A language structured around the domain model and used by all team members to connect all the activities of the team with the software.
source: http://domaindrivendesign.org/node/132
It’s a way to guarantee a shared understanding of the main terms used in a domain.
I’ll start to write more about Product Management here, so I felt the need to define Product Management prior to writing more about it.
Prior to defining Product Management, let me define product in the software development industry:
Product is any customer facing software system.
A customer facing software system is not necessarily a system which drives revenue through subscription or on-demand use. A system like a newspaper portal can be considered a product. The revenue from such a system probably will come from ads. An internet banking is another example of a customer facing system who would benefit from product management. It doesn’t drive direct revenue but it helps decreasing cost of physical bank offices.
And here goes the Product Management definition:
Product Management is accountable and responsible for everything from high-level objectives to the details of the user experience of a customer facing system. It’s the connection between the business strategy and the customer through a software system.
Do you work to earn money? Or do you work to solve someone’s problem and earning money is just a consequence of the good work you did solving someone’s problem? Earning money is one of many indicators that you’re doing a good job, but you need to know what problem are you solving and why.
Recently I read a very interesting post written by Martin Fowler on the three pillars that serve as direction to ThoughtWorks. The three pillars came from Ben & Jerry’s mission statement:
In his post, Martin used the phrase “revenue is like oxygen – you need it in order to live but it isn’t what you live for” as a metaphor to explain the sustainable business pillar. I really like this metaphor but I would like to propose another one to help explain the sustainable business pillar:
Revenue is like food: you need it in order to live but it isn’t what you live for and; eating too much or too fast or the wrong food can make you ill.
Revenue is like food:
Too much revenue: how come too much revenue is bad? Well, there are many ways that too much revenue can be harmful. If you sell at a price too high, a person may buy one time, but she’ll have the feeling that she paid too much and she probably won’t buy again. Or if you sell more than what your able serve, your customer won’t be happy. Or you sell something you are not capable of delivering, again you won’t make your customer happy.
Growing revenue too fast: how come growing revenue too fast can be bad? If you are not prepared to sell fast, you may hurt your business by providing your customer with poor product or service. They won;t be happy, they won’t return, they won’t tell their friends good things about you.
Wrong revenue: is there such a thing as wrong revenue? If you have revenue due to the causes explained in the two items above, they can be harmful to your business. Besides this, other examples are revenue from an unethical sale or revenues that can create cash now but many operational problems in the future.
Next time you are chasing a new revenue, remember the analogy with food – your business need the revenue to live, but it doesn’t live for the revenue. Is this revenue enough for your business or are you trying to put too much food in your mouth? Are you acquiring this revenue at the right pace or you are being too fast and your company won’t be able to cope with the demand? Is this a good revenue or it may hurt your company in the future even providing some cash now?
P.S.: If you like this post, you may like Purpose Beyond Profit. And if you like analogies, you may like Leading is similar to being a doctor.
