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!
I mentioned earlier about “The Checklist Manifesto” book. The post was originally written in Portuguese but you can find a Google translation here. In this post I mentioned about the use of checklist in surgeries and other medical procedures and how we could use checklists in the IT environment.
I was reviewing my Kindle highlights for this book and found this highlight:
Surgery has, essentially, four big killers wherever it is done in the world: infection, bleeding, unsafe anesthesia, and what can only be called the unexpected. For the first three, science and experience have given us some straightforward and valuable preventive measures we think we consistently follow but don’t. These misses are simple failures — perfect for a classic checklist. And as a result, all the researchers’ checklists included precisely specified steps to catch them. But the fourth killer — the unexpected — is an entirely different kind of failure, one that stems from the fundamentally complex risks entailed by opening up a person’s body and trying to tinker with it. Independently, each of the researchers seemed to have realized that no one checklist could anticipate all the pitfalls a team must guard against. So they had determined that the most promising thing to do was just to have people stop and talk through the case together — to be ready as a team to identify and address each patient’s unique, potentially critical dangers.
Surgery has, essentially, four big killers wherever it is done in the world: infection, bleeding, unsafe anesthesia, and what can only be called the unexpected. For the first three, science and experience have given us some straightforward and valuable preventive measures we think we consistently follow but don’t. These misses are simple failures — perfect for a classic checklist. And as a result, all the researchers’ checklists included precisely specified steps to catch them.
But the fourth killer — the unexpected — is an entirely different kind of failure, one that stems from the fundamentally complex risks entailed by opening up a person’s body and trying to tinker with it. Independently, each of the researchers seemed to have realized that no one checklist could anticipate all the pitfalls a team must guard against. So they had determined that the most promising thing to do was just to have people stop and talk through the case together — to be ready as a team to identify and address each patient’s unique, potentially critical dangers.
Dr. Gawande found out that in order to address the unexpected, checklists should not only include task checks but also communication checks. Dr. Gawande got to that conclusion visiting a 700,000-square-foot office and apartment complex construction site with between two to five hundred workers on-site on any give day managed by a man called Finn O’Sullivan. The volume of knowledge and degree of complexity O’Sullivan manages is impressive and it was as monstrous as anything Dr. Gawande had encountered in medicine. Here’s the explanation:
It was also a checklist, but it didn’t specify construction tasks; it specified communication tasks. For the way the project managers dealt with the unexpected and the uncertain was by making sure the experts spoke to one another — on X date regarding Y process. The experts could make their individual judgments, but they had to do so as part of a team that took one another’s concerns into account, discussed unplanned developments, and agreed on the way forward. While no one could anticipate all the problems, they could foresee where and when they might occur. The checklist therefore detailed who had to talk to whom, by which date, and about what aspect of construction — who had to share (or “submit”) particular kinds of information before the next steps could proceed. The submittal schedule specified, for instance, that by the end of the month the contractors, installers, and elevator engineers had to review the condition of the elevator cars traveling up to the tenth floor. The elevator cars were factory constructed and tested. They were installed by experts. But it was not assumed that they would work perfectly. Quite the opposite. The assumption was that anything could go wrong, anything could get missed. What? Who knows? That’s the nature of complexity. But it was also assumed that, if you got the right people together and had them take a moment to talk things over as a team rather than as individuals, serious problems could be identified and averted.
It was also a checklist, but it didn’t specify construction tasks; it specified communication tasks. For the way the project managers dealt with the unexpected and the uncertain was by making sure the experts spoke to one another — on X date regarding Y process. The experts could make their individual judgments, but they had to do so as part of a team that took one another’s concerns into account, discussed unplanned developments, and agreed on the way forward. While no one could anticipate all the problems, they could foresee where and when they might occur. The checklist therefore detailed who had to talk to whom, by which date, and about what aspect of construction — who had to share (or “submit”) particular kinds of information before the next steps could proceed.
The submittal schedule specified, for instance, that by the end of the month the contractors, installers, and elevator engineers had to review the condition of the elevator cars traveling up to the tenth floor. The elevator cars were factory constructed and tested. They were installed by experts. But it was not assumed that they would work perfectly. Quite the opposite. The assumption was that anything could go wrong, anything could get missed. What? Who knows? That’s the nature of complexity. But it was also assumed that, if you got the right people together and had them take a moment to talk things over as a team rather than as individuals, serious problems could be identified and averted.
So next time you design a checklist, remember to include not only task checks but also communication checks.
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)
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!
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.
