Readers of this blog already know Clóvis Bojikian, former Semco’s HR director. Back in 2009, when I met Clóvis, I wrote a long post about Clóvis experience in participative management.
One month ago I received a Linkedin invitation to connect with Heiko Fischer:
Salut Joaquim, I follow your blog and love it! My team made HR redundant at Europe’s largest videogames company. We called it the Way of Resourceful Humans, basically democratic entrepreneurship. I was wondering if you could get me in touch with Clóvis Bojikian. I would love to invite him! Thank you!
Doing some research I was able to find this TED presentation:
It’s easy to see that Heiko’s ideas are in synch with Clóvis experience. I instantly put them in contact and arranged for them to meet over Skype. This meeting occurred last week and it was a pleasure and an honour to be part of the conversation between those two top HR professionals so ahead of their own time. The conversation could certainly generate many posts, but I’d like to write specifically about the beginning and the end of the conversation.
In the beginning of the conversation, Heiko told a bit about his history. He told that his father worked in HR at HP and there democracy in the workplace was a value brought by the founders, so Heiko thought this was common place. Following the steps of his father, Heiko decided to work in HR as well and to his surprise, companies were far from democratic and HP was much more an exception than the rule.
At this moment, Clóvis congratulated Heiko for following his father’s steps. Normally children tend to go the opposite direction of their parents, just for the sake of opposing their parents’ opinion. Heiko replied that actually he went in the opposite direction of his father. While his father believed that in order to maintain democracy in a company it is needed a strong HR department, Heiko’s view is that the perfect democratic company is one where HR is no longer needed.
After that, the conversation followed with Heiko and Clóvis exchanging experiences, telling each other how they implemented participative management and democracy at workplace and their motivation to do so.
At the end, after Heiko hung up, I was walking with Clóvis on his way out when I mentioned how interesting Heiko’s view on HR that the perfect democratic company is one where HR is no longer needed. Then Clóvis completed “and managers are no longer needed as well”.
I mentioned earlier that I was starting:
a new project called “The startup guide: how to create and manage profitable web products”. It’s a blog that will eventually become a book where I’ll explain how to create and manage a web product with a profit.
Well, I finished writing the book which is called “The Startup Guide: how startups and established companies can create and manage profitable web products“. The book is focused on how any type of company – no matter if it’s a startup or an established company – can create and profitably manage a web software. All it’s content is available at the “Guia da Startup” blog. It’s currently in Portuguese so it’s a good opportunity for you to practice reading in a new language. If you are not up-to-date with your Portuguese skills, there’s the option of using Google Translate but some meaning may be lost in translation. For these reason I intend to translate the content into English eventually.
One of the most popular posts from this blog is about the reasons to make fast the first version of your product. Why do we need to make an MVP? Why not wait to have the product with more features to launch it? Herb Kelleher, co-founder and former CEO of Southwest Airlines has a famous phrase to motivate people to do things:
“We have a ‘strategic plan.’ It’s called doing things.”
This “strategic plan” can be translated into the #jfdi hashtag which means something in the lines of “just focus and do it” or “just freakin’ do it” (polite form).
But why the hurry? Why can’t we keep working on our product until we feel comfortable it has all the features we believe are needed to solve the user’s problem?
Well, there are 3 main reasons:
Reason #1: The moment of truth!
The longer you take to put your product in front of real users, the longer you take to start getting feedback from real people to know if you’re on the right track. And what’s even worse, you’ll probably be giving too many steps in the wrong direction.
A software is supposed to solve a certain problem of its users. You will not know if you have built a good product until the product is used by real users and it actually solves one of their problems. The longer it takes for this to happen, the longer it will take for you to know if your product is or is not the solution for someone’s problem.
And if it is not, what should you do? Change, adapt and present it again to real users! The sooner you know that what you’re developing is not on track, the better, because you’ll have spent less time, energy and money moving into the wrong direction.
Reason #2: Featuritis
There’s a limit to the number of features an user can understand. When we present a software full of features to a potential user, instead of providing her with a possible solution to one of her problems, we may end up creating a new problem for her. Kathy Sierra, a well known software development and user experience instructor, designed the Featuritis Curve that illustrates in a clear and fun way how user satisfaction diminishes as we increase the number of features of a product.
Reason #3: ROI
The longer you take to put your product in front of real users, the longer it will take for you get some revenue and the longer you’ll have to invest from your own money or investor’s money. Below is a typical return on investment chart. While you don’t launch your product and don’t have revenue, all you’ll have are costs, i.e., you’ll be in the investment phase of the curve below. This situation will only change when you get some revenue and this revenue pays your monthly costs. This is the monthly profitability phase in the chart. Only after a few months in the monthly profitability phase you’ll be able to get to the return on investment phase. It’s a long way:
Now take a look at the chart below. If you decide to delay your launch in 3 months, this can delay your return on investment in 6 months! Are the features that you intend to implement in those 3 months you are delaying the product launch worth the 6 months delay to get to the return on investment phase?
On the other hand, if you are able to launch 3 months sooner than what’s described in the first chart, you’ll get into the return on investment phase 6 months sooner. Isn’t that worth figuring out how to launch your product faster?
If you’re not embarrassed…
There is a famous quote by Reid Hoffman, founder of LinkedIn, which really resonates with the MVP concept:
“If you are not embarrassed by the first version of your product, you’ve launched too late.”
To illustrate this quote, here are some print screens of early versions of well known software products:
Next post
Last year I decided to run a lean startup experiment. Would it be possible to build a software and market it without using Locaweb’s marketing power? The result of this experiment is a calorie counter web product with more than 17,000 registered users in less than one year of operation. In my next post I’ll explain how I built the first version of this product in 10 days.
This weekend I was at QCon São Paulo, a great conference made by developers for developers.
In this conference I talked about “Guia da Startup” (Startup Guide), a blog (in Portuguese) that became a book (also in Portuguese) about product management lessons for web startups and for non-startups with web projects. I have plans to translate the content of this book to English and post it here.
Martin Fowler (@martinfowler) from ThoughtWorks gave the first keynote. At a certain point he used an interesting quote to introduce the topic of good design and technical debt.
I commonly come across developers who are frustrated because “management want more features, they don’t care about quality”
The quote got my attention specially because as a developer talking to developers in a developer conference, Martin focused on the part of the quote that normally drives the attention of all developers, the “how” part. He focused on the “quality” word to explain how important it is to have good design to avoid technical debt so developers can add more features more easily. As I’m more focused on the product management side of software development, as soon as I read the quote, I focused on the “why” part. This motivated me to create a new slide in my presentation about product management practices:
When I heard the quote, my focus was directed directly to the word “features” and my first reaction was asking “Why is this feature being requested?”
When we are asked to implement a feature in a software, the natural reaction is to think how this feature will be implemented. However, we need to give a step back and understand what we are trying to achieve implementing this feature. What value this feature brings to the software users? What value this feature brings to the software owners? Every new feature, no matter how small it is and how simple it is to implement, creates complexity in our code. What’s the value we expect out of this additional complexity? This is a question that not only a product manager should ask, but every developer who is asked to implement a feature should ask.
So my recommendation to every developer who’s asked to implement a feature is, before rushing to figure out “how” a feature should be implemented, question “why” this feature is being asked. This will help you understand the importance of the feature and help who’s asking the feature to reassure the motivation behind this feature.
I was reviewing ThoughtWorks latest version of their Technology Radar, which is a great source of information to help you know what’s hot in terms of software development and IT management, and notice it doesn’t mention Product Management (or you can call it Product Ownership) and put Experience Design (XD) only at the “assess” sector of the technique area of the radar.
In my view, Product Management and Experience Design are techniques as critical to successful software projects as DevOps, Continuous Delivery, Testing, Agile and Lean.
It is quite difficult to develop good software without those two roles and their techniques. Both should be in the “adopt” sector of the technique area of the radar.
Product Management is not only for systems that will become a product, but for any system, since any system will have users. The Product Management role is the link between system users and the team who will build the system. It is different from the Business Analyst role which is more focused in the business and the owners of the system. And its different from Experience Design role which is more focused on how a user interacts with a system.
The Product Management role is responsible for talking with real users of the system, understanding the pain that the system is supposed to solve for these real users and help define what needs to be developed. Note that a system may be owned by a company, like a ticketing system or an ecommerce system, and this company who owns the system will ask for a certain set of features so they can reach a certain business goal, but the requirement gathering is incomplete if we don’t listen to the real users of the system who normally are customers of the company who owns the system.
If you have a great group of developers, QAs and BAs, all veterans in using Agile, Lean, Testing, DevOps and Continuous Delivery, all of that is useless if you are not able define what is the minimal set of features that can create value for the customer in the first release. And subsequently define the minimal features to be developed and deployed that brings greatest value to real users. The Lean Startup movement calls it MVP (Minimal Viable Product). Mark Denne and Jane Cleland-Huang, authors of Software by Numbers, first published in 2003, coined another term for this minimal set of features. They call it MMF (Minimal Marketable Feature).
The Agile Manifesto says that we should value “Customer collaboration over contract negotiation” and set as it’s first principle that “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software”. The issue with these two statements is that it assumes that the customer who is the owner of the system knows what is “valuable software”. However, the customer normally knows what is “valuable software” for him, i.e., they know what are their business goals that they want to achieve with the system. The problem is that the customer doesn’t know their own customers enough in order to define the requirements upon what a system should be developed, i.e., the customer doesn’t know what is “valuable software” for their own customers.
It is the Product Manager’s role to understand the users, the problem the users have, and should bring this information back to the developers and experience designers so these three roles can jointly come up with a system that solves the users problem and, at the same time, meet the system owner’s business goals.
What do you think? Do you agree? Disagree? Share your comments below!
I already mentioned about “The Checklist Manifesto” book in two previous posts, one explaining how important it is to use checklists, and another one on using checklists to deal with the unexpected.
In this post I’ll reproduce some of my highlights from the book. These highlights provide advice on how to create a good checklist:
Pilots nonetheless turn to their checklists for two reasons. First, they are trained to do so. They learn from the beginning of flight school that their memory and judgment are unreliable and that lives depend on their recognizing that fact. Second, the checklists have proved their worth—they work.
There are good checklists and bad, Boorman explained. Bad checklists are vague and imprecise. They are too long; they are hard to use; they are impractical. They are made by desk jockeys with no awareness of the situations in which they are to be deployed. They treat the people using the tools as dumb and try to spell out every single step. They turn people’s brains off rather than turn them on. Good checklists, on the other hand, are precise. They are efficient, to the point, and easy to use even in the most difficult situations. They do not try to spell out everything—a checklist cannot fly a plane. Instead, they provide reminders of only the most critical and important steps—the ones that even the highly skilled professionals using them could miss. Good checklists are, above all, practical.
No matter how much thought we might put in, a checklist has to be tested in the real world, which is inevitably more complicated than expected. First drafts always fall apart, he said, and one needs to study how, make changes, and keep testing until the checklist works consistently.
The checklist cannot be lengthy. A rule of thumb some use is to keep it to between five and nine items, which is the limit of working memory.
You must decide whether you want a DO-CONFIRM checklist or a READ-DO checklist. With a DO-CONFIRM checklist, he said, team members perform their jobs from memory and experience, often separately. But then they stop. They pause to run the checklist and confirm that everything that was supposed to be done was done. With a READ-DO checklist, on the other hand, people carry out the tasks as they check them off—it’s more like a recipe.
I’m starting a new project called “The startup guide: how to create and manage profitable web products”. It’s a blog that will eventually become a book where I’ll explain how to create and manage a web product with a profit. The blog and the book will be originally in Portuguese. Unfortunately, because of the due date of the book, I won’t have time to translate the content here as soon as I write it in Portuguese but, if you don’t speak Portuguese, you still can read it using Google translate to help you have sense of what I’m discussing there:
As soon as I have some time available, I’ll be back here translating that material to English.
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.
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.
In phase 3 I launched the website, the online campaign, got real users feedback and improved the system based on this feedback.
My phase 4 main objective was the search for revenue!
I was getting at a point were I needed minor changes to the system and every change to the system was going to cost me too much, not only in money but in time, since freelance developers are not available whenever you need them. I’m an old programmer… My last production code was in Perl. At that time, Microsoft ASP was new stuff and no one ever heard of PHP. This was 1998.
As soon as I got the database access, I wrote a simple Perl application to generate statistics so I could check how the app was going, how many users signed up and so on.
Due to my familiarity with Perl I was tempted to write more code using this language but since this is an experiment, I decided to get the source code from the source code repository (GitHub), try to run the application locally on my machine, make some changes, test it, send it back to GitHub and then deploy in production. It worked!
Now the doors were really open to full experimentation. The site was based on WordPress, so I could change it to certain degree anytime I wanted. And now the application I could also change – to a certain degree – anytime I wanted, so it’s time for some experiments.
Prior to charging users for using the system I decided to run a survey so I could have a better understanding of how the users view the product. The first question was about the NPS (Net Promoter Score), a customer loyalty metric:
The Net Promoter Score is obtained by asking customers a single question on a 0 to 10 rating scale, where 10 is “extremely likely” and 0 is “not at all likely”: “How likely is it that you would recommend our company to a friend or colleague?” Based on their responses, customers are categorized into one of three groups: Promoters (9–10 rating), Passives (7–8 rating), and Detractors (0–6 rating). The percentage of Detractors is then subtracted from the percentage of Promoters to obtain a Net Promoter score (NPS). NPS can be as low as -100 (everybody is a detractor) or as high as +100 (everybody is a promoter). An NPS that is positive (i.e., higher than zero) is felt to be good, and an NPS of +50 is excellent. Companies are encouraged to follow this question with an open-ended request for elaboration, soliciting the reasons for a customer’s rating of that company or product.
Source: Wikipedia
ContaCal’s NPS was 65%, a very good index.
ContaCal NPS
The second question was about how much the user was willing to pay for the service.
How much would you pay?
39% of the users were willing to pay for the service and the average price they were willing to pay was around 5 BRL per month.
We also asked about nutritionist counseling as part of the service and in this scenario, 42% of the respondents were willing to pay an average price of 20 BRL.
Nutritionist counseling
The last question was about ad supported business model. I was not surprised that 94% of the users preferred the free ad supported option.
Ad supported
My first experiment was with ads. The option at hand was Google AdSense, so I implemented it in the website as well as inside the application. The results were not very compelling.
I experimented with AdSense during one month. I had close to 85K pageviews and 20.5K unique visitors. This generated U$ 32.19 in revenue.
Next step was billing. Here in Brazil we have boleto bancário, an alternative to credit card for receiving payments.
Boleto Bancário is a financial document, a kind of proforma invoice issued by a bank that enables your client to pay the exact specified amount to the receiving party (merchant). As long as within the due date period, your client may use a lotto house, supermarkets, post offices, home banking in addition to any bank agency in the Brazilian territory.
Source: The Brazil Business
I implemented initially boleto bancário using Cobre Grátis service. I had some issues that made me change to credit card. For credit card processing I used PayPal. Quite useful since they provide recurring payments as well as international payments, which was quite handy since ContaCal was also attracting some users from other Portuguese speaking countries and I do have a few subscribers from abroad!
After using credit card only lots of user were asking for boleto, so now I offer both options.
Some time ago I showed my initial user statistics:
ContaCal users 08/2011 through 10/2011
Below you can find the follow on statistics up to February 2012, not only for users but also subscribers:
ContaCal users from 11/2011 through 02/2012
ContaCal subscribers from 11/2011 through 02/2012
One thing that is really important is to have a log of all the tests made so you can relate each of the experiments to the numbers you see in your charts.
Below are the results of 6 months of my lean startup validation experiment.
ContaCal numbers
Under Mkt costs is AdWords and Facebook Ads. Under Infra costs are all infrastructure costs including hosting, email marketing tool, domain registration, unbounce and any other SaaS tool required to run ContaCal. Under Dev are all the development costs including not only the Startup DEV but also the WordPress theme acquired at themeforest as well as the designer who worked on implementing the theme in the WordPress.
Now I need to work on reducing those costs as well as keeping the revenue growth.
Since I was able to find some revenue, now it is time to search for profit. Some of the areas I’ll work on during next phase:
See you there!
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.
