When we treat software development as a project, we are giving it a start and an end, since all projects have clearly defined starts and ends. If we think about starts, that’s ok. All software development efforts have a clearly defined start.
However, when we talk about end, software development and the software which is the product of the software development process may have an end but:
For this reason both software development and the software which is the product of the software development process may have an end, but it is a clearly defined end. When we treat software development as project we are forced to define an end for this development since projects require a clearly defined end. In this situation we tend to define the software development end as the delivery of the software first release. But what happens after this delivery? Aren’t we going to do anything new in this software? Or should we start a new project to work on the next release of the software? If we decide to start a new project, what we will do while we don’t start to work on this new version?
This is why companies have started to treat software development as a continuous process, not a project, and the software as a product of this process. Software is a product with a clearly defined start, but no clearly defined end. The history of a software product is written during the life cycle of this product and the end depends a lot on the decisions made during this life cycle.
Hence the need of software product management in our industry.
Product Management book
Are you interested in the software product management topic? Do you to learn more about it? I wrote a book about the topic. The book has 5 main sections:
This book is recommended not only for those who have software as her core business. Companies who develop tailor made software as well as companies who use software to communicate with its customers like banks, schools, hospitals, etc., can also benefit from the book.
Interested? Well, the book is currently only available in Portuguese. So if you can read Portuguese, get your copy today!
If you don’t speak Portuguese, don’t worry! Paulo Caroli and I are working on translating the book into English, so feel free to leave a comment below, and we’ll let you know when the book is ready.
ThoughtWorks is a well known software development company which is always one step ahead of the rest of the software industry. Many people who contributed and continue to contribute to our industry are – or were – ThoughtWorkers. Martin Fowler, Jeff Patton, Neal Ford, Jim Highsmith, Rebecca Parsons, Ola Bini, Jim Webber, Luca Bastos, Paulo Caroli, Claudia Melo are just a small sample of people who work – or worked – there and have contributed a lot for the evolution of the software industry.
Since 2010 they publish a document called Technology Radar where they talk about their view on techniques, languages, platforms and tools for software development. This view is based on the experience from their consultants who work on a variety of software development endeavours from customers all over the world. They classify the techniques, languages, platforms and tools in four main categories:
In May 2015 I was quite pleased when May’s Technology Radar edition brought “Products over Projects” as new technique and already recommended it as TRIAL. This showed that ThoughtWorks started to believe that software development should not be viewed as a project with a clear start and finish, but rather as a product, developed to support business processes of the owner of the software. This software will have a long life cycle, so long as the life cycle of the business processes it supports. For this reason, software development should not be viewed as a project with a predictable end, but rather as a product, a tool that will support the business processes for as long as the business processes exist.
I wrote about the differences between a product and a project back in 2011 and the more I work with software development, the more it get clearer to me that we should manage software development as a product, with a long lifecycle, with an unpredictable end. For this reason product management is so important for software development.
From trial to adopt
When I saw the November 2015 Technology Radar edition I was even more pleased when I saw that ThoughtWorks decided to move “products over projects” from trial to adopt. Doing so they now consider software product management as a technique that they feel strongly that the industry of software should be adopting in order to increase the chances of success of their software. Here it is in their own words:
We’ve long been championing the idea that thinking of software development as a project – something budgeted and delivered during a limited time slot – doesn’t fit the needs of the modern business. Important software efforts need to be an ongoing product that supports and rethinks the business process it is supporting. Such efforts are not complete until the business process, and its software, cease to be useful. Our observation of this products over projects approach, both with our own projects and outside, makes us determine that it is the approach to use for all but exceptional cases.
Certainly this will help people all over the world in creating better software, which will meet the needs of their customers while helping the software owners reach their objectives.
This is a great step forward for the software industry! This is great step forward for software product management! \o/
Whenever errors occur, some people have a natural tendency as their first reaction to look for someone to blame. Specially in group activities. As if having someone to blame would somehow make the error less harmful. This is a big waste of time and energy. Let me explain why.
Waste of time
An error occurred. Errors happen. This is a fact of life. No matter what you are doing, designing software, deploying code in production, operating on a patient, cooking dinner, building a house, playing guitar, playing soccer, etc. chances are that erros will occur.
When you spend time trying to find who was responsible for the error, you’ll delay your most important tasks regarding the error:
Waste of energy
When you spend time trying to find who was responsible for the error, people may naturally try to hide because they are afraid of the consequences. Will I be fired? Will I be excluded from the group? Will I be punished? Will people mock me?
When people try to hide who was responsible, you’ll again delay your most important tasks regarding the error listed above because it will be more difficult to understand what happened. People will not tell the whole truth and nothing but the truth about the error and the circumstances surrounding the error.
Deal with the responsible in private
If in the process of understanding what happened you find out that someone was responsible for the error, deal with him in private. Most probably he caused the error without intention to do any harm. So on one side you need to help him improve so he doesn’t do this kind of errors in the future. On the other side you have the responsibility to create an environment where it’s safe to tell about the errors so these errors are detected more quickly.
When an error occur, don’t waste your time on who’s to blame.
Focus your energy on understanding what happened.
Figure out how to fix it.
Find ways to prevent the error from happening again.
If you find out someone was responsible, deal with him in private, and help him improve.
I have talked to some people lately about IT departments and how they seem disconnected from the companies they belong to, often being very reactive to business demands. It is common to hear complaints from the business people about IT saying they almost never deliver what was asked and that it is hard to understand what they say. On the other hand, it is also common to hear IT folks saying that the business area does not know what they want and that IT cannot answer “zillion” high priority demands of the business. This lack of understanding between IT and the business area of the company is so common that it even became a subject of cartoons of all kinds:
But what is wrong? What is the IT problem?
For those who live in the part of IT that has to do with software development, this problem has been addressed for some time now. The Agile Manifesto, from 2001, makes this clear:
We have come to value customer collaboration over contract negotiation.
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Business people and developers must work together daily throughout the project.
As the software developers need to deploy their software somewhere, they decided to involve the people who takes care of the production environment in this new way of thinking that bring together IT and business. Thus was born the DevOps movement in 2009:
DevOps (a portmanteau of development and operations) is a software development method that stresses communication, collaboration and integration between software developers and information technology (IT) professionals. DevOps is a response to the interdependence of software development and IT operations. It aims to help an organization rapidly produce software products and services.
In these software development teams it is common to see someone with the role of Product Owner or Product Manager. This is a role I’ve already described earlier:
Product Manager is responsible for all aspects of a software product, from strategic objectives to the details of the user experience. She is responsible for making the connection between the business strategy and the problems and needs of customers through the software that should help the company achieve its strategic objectives while solving the problems and needs of the customers.
The IT problem
Now imagine the IT department of Gap, American Airline, Disney, MIT or any other non-tech company. These IT departments will have among its scope the following functions:
As you can see, these IT departments already have enough stuff to worry about and will hardly develop software. If they choose to develop software, they will most likely use third parties to do this development. Even if they decide to develop internally, software development is still a small piece of IT. The concern of these IT areas is with how to integrate off-the-shelf software and make them work to meet the business needs.
The problem is that unlike software development, which already discovered the importance of having a product manager to help deliver results more aligned with the business, all other functions of an IT department does not have this bridge between IT and the business.
One possible solution to the IT problem
I would like to propose a solution to the IT problem: have more people with the role of “product manager”. I believe that name does not fit very well when the IT delivery is not software. That person will need to create a bridge between IT and business. Perhaps a more appropriate name is “business manager”.
This person would have the following responsibilities:
And to be able to carry out these responsibilities, this person needs to have:
As you can see from the above description, this person have a senior profile. It will be a pair of the IT manager.
A question that may arise while reading this proposal to add a “business manager” to the IT team is why IT managers can not assume this role? Actually, they can, but they shouldn’t. IT managers already have many concerns. The IT manager has two main focuses, technology and people. She needs to be up-to-date on the technologies in her area to learn how to better meet the needs that arise. And she needs to manage the team, finding and coordinating good IT professionals is no an easy task. Putting on the IT manager the additional burden of business requirement management can lower the overall quality in current tasks.
In software development we’ve realized that it’s better to have a separate person taking care of business needs. Why not apply the same role separation for other IT areas?
By the end of October I went to Business of Software conference, an interesting conference about, well, the business of software. Many interesting speakers and interesting people in the audience to chat.
One of the presentations was given by Scott Berkun, who was team lead at WordPress.com from 2010 to 2012. WordPress.com has over 10 billion page views per month, fewer than 200 employees and everyone gets to work from home making it a very interesting environment to think about the future of the workplace. He told us about the advantages and challenges of a distributed work environment, what we can consider as an innovation in management. His presentation was very interesting but when he got to the Q&A session, he got the inevitable question about Yahoo! and their move back from the remote working policy. His answer was very straight forward: since Yahoo! is in a crisis, they cannot afford the management innovation, it is natural that they revoked this policy and returned to traditional management practices, in this case, co-location of workers.
So this got me thinking, whenever a company faces a crisis, it should stop innovation management and should go back to traditional management?
Participative management in a crisis environment
Today I had again the opportunity to join a conversation with Clóvis Bojikian and Heiko Fischer. This was the third or forth encounter we had and, as always, the conversation was very interesting, full of ideas, examples and how-tos related to participative management.
At a certain point Clóvis told about a crisis at Semco, during the Collor president years, where the market was abruptly opened to foreign companies. That impacted Semco and forced them to do a downsize, which is always painful. Clóvis discussed with the workers how they wanted to do it and the workers told that they would provide a list of people that should not be laid off either because of age or personal issues and they said to the managers that, preserving the people in that list, the manager could select who should be laid off based on technical criteria. Two things we can pick from this episode:
It takes a tyrant to sustain participative management
Back in 2008 I read a very interesting article entitled “Sometimes It Takes a Tyrant to Support Collaboration“. We were in the initial steps agile implementation at Locaweb and this article showed that even though one of the outcomes of agile implementation would be self managed teams, this was not a natural outcome, and it requires a constant push from leaders to move into that direction.
Now I have the impression that the same happens with participative management. Even though this is an outcome appreciated by many workers, this is not a natural outcome. It requires that someone forces and sustains the move into this direction. Clóvis and Ricardo Semler did that at Semco. Heiko did that at the largest video game maker in Europe. I did that with my teams at Locaweb. We need to force and reinforce this behavior until it is imprinted in the company’s or team’s culture.
Heiko told about a decision they made in a company facing an economic crisis where the options where to either lay off people or cut 20% of the salaries of everybody so there won’t be any lay offs. Obviously the team preferred the second option. I said to Heiko that in Brazil that’s not an option since we can’t reduce salaries. He told that this is not possible in Europe either, but they figure out a way to do it. Employees would deposite 20% of their salaries in a company fund. At this moment Clóvis told that they also did that at Semco, in agreement with the Union.
Another exemple given by Clóvis was about employee time tracking. In Brazil it is required to have time tracking of all employees but at Semco they wanted to free up the workers from this hassle and show them they trust them. Even though they were subject to a fine if they didn’t do time tracking, they decided to pay the fine but keep off the time tracking to show workers their trust. So they found a way to support participative management even if it has costs.
This is an interesting paradox: in order to implement participative management you need to force it’s implementation, it doesn’t just happen. You need to force and sustain the movement into this direction, even more in crisis.
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:
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:
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., he knows what are his business goals that they want to achieve with the system. The problem is that the customer doesn’t know his own customers/users 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 his own customers/users.
It is the Product Manager’s role to understand the users of a product/system, 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 product/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.