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)
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!
There’s a Seth Godin’s post that I always use as a reference:
Gravity is a constraint. If you’re a designing an airplane, it would be a lot easier without gravity as a concern, but hey, it’s not going away. A problem is solvable. A constraint must be lived with. … The art is in telling them apart.
Gravity is a constraint. If you’re a designing an airplane, it would be a lot easier without gravity as a concern, but hey, it’s not going away.
A problem is solvable. A constraint must be lived with.
…
The art is in telling them apart.
Source: Problems and constraints
This post always reminds me of that old saying that tell us pick our battles carefully. Specially if the battle is a constraint.
I mentioned earlier that one of the sources I’ve been reading and enjoying is Jurgen Appelo’s posts about agile management. I’ve been reading his posts for a while, since the time he was the CTO of a dutch company. I really like the way he connects agile methodologies and complex adaptive systems theory.
I’ve mentioned his work in 4 posts:
Now he is 100% focused on his agile management coach career. He recently launched a book entitled “Management 3.0: Leading Agile Developers, Developing Agile Leaders“.
He also provides Agile Management courses.
Last week he was in São Paulo providing his management course at AdaptWorks and I had the opportunity to attend his course.
I’ll make a brief summary of the course below, as a way for me to review what we discussed during this two days. However, I strongly advise any leader, even from non software related areas or companies, to attend. Even though the ideas and insights Jurgen provides during the course are very good and he is an excellent presenter, you can read them in his blog and in his book. What is great in this course is the opportunity to practice and discuss the ideas and insights with Jurgen and the other attendees and the chance to exchange experiences.
After a quick introduction about the ideal size of a group and quick introductions of the attendees, Jurgen explained quickly about agile software development and then introduced Martie, the Management 3.0 representation with the 6 aspects of management that we should take care if we want to be good managers.
Martie
Then Jurgen explained briefly about the theory of complex systems and the types of fallacies we may fall into if we don’t use complex systems thinking when managing teams.
The seven fallacies
To end the introductory section, we did a group exercise where we analyzed some situations to identify what was the fallacy in play.
When discussing about people, Jurgen talked about intrinsic and extrinsic motivation and presented us with the 10 intrinsic desires:
Intrinsic desires
Exercise time: we analyzed individually how we are in our current jobs in terms of each of these 10 intrinsic desires.
Then Jurgen presented some tools to helps us know what is important for the people in our team:
B = f (P, E)
Group exercise: we had to use the practices below to get to know 10 important facts about Ellen, a member of a fictional team managed by us.
Here Jurgen presented the 7 delegation levels I already mentioned in a previous post.
Delegation levels
Group exercise: delegation poker where we were presented with different situations where we needed to figure out the appropriate delegation level.
A leader must:
The 4 I’s to cope with the Tragedy of the Commons:
3 kinds of purpose (or goal) for a team:
Qualities of a good goal
Exercise time: we had to define a purpose for the course.
First Jurgen described how we can improve.
Competency development
Then he described how we can measure our improvement.
KPI matrix
Exercise time: we had to define KPIs according to the matrix above to our organization.
We can have two types of team organization, functional or cross-functional, it depends on how often team members need to communicate. Product managers, user experience designers and software developers need to communicate all the time about the project or product they are working on, so they need to sit together in a cross functional team. HR people on the other hand need to talk constantly to other HR people so they need to sit in a functional HR team.
Jurgen also advised we should hire generalizing specialists, promote informal leadership and widen job titles.
Exercise time: Meddlers.
Meddlers
How can I…
In order to change things we need to consider:
The system
The individuals
The interactions
The environment
Culture changes only after you have successfully altered people’s actions, after the new behavior produces some group benefit for a period of time.
John P. Kotter, Leading Change
Exercise time: each member of the group tell one story with she needs ideas on how to change, then the group select from the list above and discuss.
This is just a brief summary of the 2-day course, as a way for me to review what we discussed during. However, I strongly advise any leader, even from non software related areas or companies, to attend. Even though the ideas and insights Jurgen provides during the course are very good and he is an excellent presenter, you can read them in his blog and in his book. What is great in this course is the opportunity to practice and discuss the ideas and insights with Jurgen and the other attendees and the chance to exchange experiences.
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:
I recently read the post “And” Leadership written by Jim Highsmith that caught my attention on using AND instead of OR:
One of the traits I think is very important [for an agile leader or manager] is that of “And” rather than “Or” leadership. The most pressing issues to face leaders are usually paradoxical; they appear to have contradictory solutions. Take for example the paradox of needing predictable delivery with that of needing to be flexible and adapt over the life of a project.
It’s easy to be an “or” leader. Pick a side and state your case loudly, over and over until the opposition gives up. It’s much more difficult to be an “and” leader, balancing between seemingly opposite strategies. However, in our ever-changing and turbulent world, slavishly following the “one right answer” is a recipe for disaster.
It’s interesting that in many situations in agile development we face situations where we initially think it’s an OR situation but when we analyze it, we realize it’s actually an AND situation where we need to balance apparently opposing concepts:
It’s interesting that this applies not only to agile development but to many aspects of our life. Should I be more concerned about my family or my job? Should I give more attention to my kids or my companion? Experiment changing or by and.
Next time you face a situation with opposing concepts, instead of choosing the easy path of taking sides and being an OR person, try to figure out a way to be an AND person. It will be much more difficult to ben an AND person. Sometimes it won’t even be possible to use AND in certain situations, but just trying to figure out if it is possible will be a good exercise with interesting outcomes.
