ThoughtWorks finalmente move “products over projects” de trial para adopt

A ThoughtWorks é uma empresa de consultoria em desenvolvimento de software bastante conhecida por estar sempre um passo à frente da indústria de software. Várias pessoas que já contribuíram e continuam contribuindo para nossa indústria são ou já foram ThoughtWorkers. Martin Fowler, Jeff Patton, Neal Ford, Jim Highsmith, Rebecca Parsons, Ola Bini, Jim Webber, Luca Bastos, Paulo Caroli, Claudia Melo são só alguns exemplos de nomes de pessoas que trabalham (ou já trabalharam) nessa consultoria e contribuem muito para a evolução de indústria de software.


Desde 2010 eles publicam seu Technology Radar com sua visão sobre técnicas, linguagens, plataformas e ferramentas relacionadas a desenvolvimento de software. Essa visão é formada a partir da experiência de seus consultores trabalhando nos mais variados projetos de desenvolvimento de software em clientes de todo o mundo. Eles classificam essas técnicas, linguagens, plataformas e ferramentas em quatro categorias:

  • Hold: algo que aparece como hold, pode ser de algum interesse, mas não é recomendado investir muito.
  • Assess: quando algo aparece ou move para assess, já vale investir algum tempo para entender qual o impacto dessa técnica, linguagem, plataforma ou ferramenta.
  • Trial: quando algo aparece ou move para trial, além de investir algum tempo entendendo é importante também experimentar a técnica, linguagem, plataforma ou ferramenta.
  • Adopt: e finalmente, quando algo chega ao estágio de adopt, definitivamente é uma técnica, linguagem, plataforma ou ferramenta que deve ser incorporada no seu processo de desenvolvimento de software.

Em maio de 2015 eu já fiquei bastante feliz quando o Technology Radar trouxe como novo item o conceito de “Products over Projects” já classificado como trial. Em resumo, eles enxergam que desenvolvimento de software não deveria ser encarado como um projeto com começo, meio e fim, mas sim como um produto, que suporta processos da empresa que é dona do software, e que necessita de manutenção durante todo o seu ciclo de vida, que será tão longo quanto o ciclo de vida do processo de negócio que esse software suporta.

Ou seja, finalmente a ThoughtWorks começa
a enxergar a importância da Gestão de Produtos
para o sucesso do software!

De trial para adopt

Qual não foi minha alegria ao ver que, no último Technology Radar, publicado agora em novembro, a ThoughtWorks mudou “products over projects” de trial para adopt. Com isso, eles passam a considerar a Gestão de Produtos como algo que deve ser adotado no processo de desenvolvimento de software com o objetivo de aumentar as chances de sucesso desse software.

Certamente isso ajudará a termos softwares cada vez melhores, que atendam as necessidades de seus usuários ao mesmo tempo que ajudará o dono desse software a atingir seus objetivos.

Isso é muito bom para a indústria de software. Isso é muito bom para a gestão de produtos de software! \o/

The IT problem

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?

Software development

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.

Source: Wikipedia

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:

  • Hardware inventories.
  • Software inventory and installation.
  • Server availability monitoring and metrics.
  • Security management.
  • Anti-virus and anti-malware management.
  • Anti-manipulation management.
  • User’s activities monitoring.
  • Capacity monitoring.
  • Storage management.
  • Network capacity and utilization monitoring.

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:

  • Gather IT needs in all areas of the company and identify and propose solutions to any conflicts between these needs.
  • When these requirements have impact on the end customer of the company, understand this impact on these customers.
  • Negotiate requirement implementation priorities with all business areas.
  • Work with IT teams to ensure that deliveries are made in accordance with the requirements gathered with the other departments of the company.
  • Act with the demanding areas and IT teams on any relationship with suppliers / partners. (e.g. banks, consultants, etc.)
  • Inform all areas of the company on new IT implementations as well as upcoming implementations. Prepare training as needed.
  • Work with marketing to inform customers when the new implementations are customer facing.
  • Define, track and analyze usage metrics from IT, to use them as further relevant information for decision making.

And to be able to carry out these responsibilities, this person needs to have:

  • Experience working with IT teams to deliver quality projects within expected deadlines.
  • Good understanding of IT and technical topics to be able to negotiate delivery options. Having been in the IT field is not required, but may help in the function.
  • General knowledge about the company’s products and services, as well as an understanding of the different departments of the company.
  • Good oral and written communication skills.
  • Negotiation skills between different stakeholders with different priorities.
  • Ability to documente requirements and use cases.
  • Leadership.

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?

Why the hurry to launch an MVP?

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:

Google in 1998

Twitter in 2006

Linkedin in 2005

Facebook login screen in 2005

Facebook in 2005

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.

As aparências enganam!

Quando comentei sobre teste A/B, mostrei um teste que fiz na home do ContaCal, que apresentou o seguinte resultado:

Resultado do teste A/B na home do ContaCal

Resultado do teste A/B na home do ContaCal

Esse resultado dá a impressão que se eu colocar botão verde com a imagem da família saudável, vou aumentar mais ainda as conversão, não é? Pois bem, fiz esse teste e veja que interessante:

Resultado do teste A/B na home do ContaCal com foto de família saudável

Resultado do teste A/B na home do ContaCal com foto de família saudável

Por isso, tome cuidado, as aparências enganam! Faça experiências antes de tirar conclusões!

Próximo post

No próximo post vamos começar a falar sobre como aplicar tudo o que foi visto aqui no Guia da Startup em empresas que não são startups.


Por esse vc não esperava, né? Nem eu! Vc já fez experimentos assim? Se surpreendeu com os resultados? Compartilhe!

How to create a good checklist

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.

Mantenha um diário de mudanças

Falei no último post que só ia escrever de novo na semana que vem, mas acabou de me ocorrer uma ideia de post que pode até ser o primeiro de uma categoria que vou chamar de dicas rápidas, em contra-ponto aos posts mais longos que tenho escrito. São dicas que vou aprendendo no dia-a-dia da Locaweb, do ContaCal e em conversas com outros desenvolvedores de produto web e que vale a pena compartilhar por aqui. Então aqui vai a primeira dica rápida.

Quando foi?

A gente acaba se fazendo essa pergunta quando vai analisar os números de nosso produto web e vê que houve mudança no número de trials, ou de conversão de trials para pagantes, ou de alguma outra métrica que acompanhamos e pensa:

“Ah, pode ser aquela mudança que fizemos no site. Quando foi? Será que foi ela que impactou a nossa métrica?”

Dica: mantenha um diário de mudanças

A dica é manter um diário de mudanças, que pode ser um arquivo texto, uma planilha, ou mesmo um caderno. Não importa muito aonde se anota, mas sim ter a disciplina de anotar as mudanças que vc fizer em seu produto web. Anote a data, a mudança feita e o que vc espera com aquela mudança. Quem é mais técnico pode ter a tendência de querer anotar somente mudanças no software, mas o ideal é anotar todas as mudanças. Fez alguma alteração na campanha de AdWords? Anote no diário de mudanças. Mudou algum texto no site? Anote no diário de mudanças. Publicou um novo texto no blog? Anote no diário de mudanças.

Assim, da próxima vez que vc olhar suas métricas e vir alguma mudança em seus números, basta olhar seu diário de mudanças para ver qual mudança pode ter originado essa alteração em seus números e se isso correspondeu às expectativas que vc tinha anotado.

Escolhendo o que terceirizar, um caso prático

No post anterior falamos sobre os diferentes áreas de conhecimento envolvidas na criação de um produto web. Algumas delas não são terceirizáveis, outras são, e outras são parcialmente.

Vou contar aqui sobre como foi desenvolvido o ContaCal, um sistema onde o usuário registra suas refeições e recebe a informação não só de quantas calorias ingeriu como também da qualidade das calorias ingeridas. Como eu escolhi essa ideia dentre várias ideias que poderiam ser desenvolvidas será tema de um post futuro. Quero me focar aqui no fato de que, após ter escolhido um problema para resolver e de ter pensado numa solução, eu tinha que concretizar essa solução e, para fazer isso, eu precisaria definir o que eu ia fazer e o que eu ia terceirizar.

Lembrando que gestão do produto, ou seja, descobrir pessoas com problemas que precisam ser resolvidos, descobrir que problemas são esses e qual desses problemas vale a pena resolver e gestão do projeto, ou seja, garantir que todas as peças (software, site, design, marketing, campanha, produto, etc.) estão em sincronia, não podem ser terceirizadas, sobram para ser terceirizadas:

Desenvolvimento de software

Tentei começar a desenvolver o sistema eu mesmo mas meus conhecimentos de programação estavam bem desatualizados. O último código que escrevi e que foi para produção era em Perl. Se não me engano, isso foi em 1998. Nessa época o ASP da Microsoft era novidade e, apesar de já existir PHP, ninguém ainda tinha ouvido falar nele… 🙂

Resolvi então terceirizar o desenvolvimento com o pessoal da StartupDEV que em 48 horas entrega um produto mínimo funcionando baseado nas especificações que vc entregar. Uma outra opção bacana é o pessoal da CodeMiner42. Eles têm ajudado bastante em alguns projetos de novos produtos dentro da Locaweb com bastante agilidade.

Experiência do usuário

Na terceirização do projeto com a StartupDEV, eu fiz todo o desenho do fluxo de interação, entregando para eles um wireframe, um rascunho de como deve funcionar a interação do usuário com o sistema. Esse rascunho eu fiz usando Powerpoint:

Como no time do StartupDEV tinha um designer, eles propuseram uma nova versão para a interface, que acabei achando bem melhor que minha ideia original e aceitei.

A experiência do usuário não é só o desenho do fluxo de interação do usuário com o sistema. É também o desenho visual. Para o desenho visual usei dois recursos terceirizados:

  • logo: para fazer o logo usei um sistema de crowdsourcing que funcionou muito bem, chamado We Do Logos. Fiquei bastante satisfeito com as opções de logo que recebi e a opção final que escolhi me agradou bastante.
  • design do site: para o design do site usei um desses sites de templates para WordPress. Achei o template FreshServe no site themeforest. Precisei de ajuda de uma profissional para me ajudar aplicar esse design em um blog WordPress.

O pessoal do StartupDEV fez a parte visual da aplicação baseada no tema de WordPress que eu tinha adquirido e no logo.

Marketing de produtos

Toda a comunicação do site, dos emails que seriam disparados pela aplicação e da campanha de AdWords, eu mesmo cuidei e continuou cuidando até hoje.

Administração de sistemas

A escolha de onde ia ficar a aplicação foi feita pelo pessoal do StartupDEV, que escolheu o Heroku pela facilidade em colocar uma aplicação Rails rodando lá. Acabei herdando esse ambiente para administrar e tive que aprender a administrá-lo na marra. Uso um serviço gratuito chamado Pingdom para monitorar se a aplicação está rodando. Já tive problemas de a aplicação não aceitar mais novos usuários por não mandar mais emails de confirmação de cadastro devido a ter atingido o limite de envio do SendGrid, add-on do Heroku para disparo de emails. Conversei com o pessoal do StartupDEV para mudar a lógica de cadastro da aplicação para não ter mais confirmação, mesmo correndo o risco de abrir uma brecha de segurança futura de, quando o sistema tivesse cobrança (como hoje de fato tem), clientes mais espertos poderem burlar o sistema de cobrança e ficarem criando contas grátis uma atrás da outra sempre que vencer o trial. Outro item que está na lista de “coisas a fazer” de administração de sistema é instalar o NewRelic, serviço de monitoração de performance específico para aplicações Rails.

Tema do produto web

O tema do ContaCal é nutrição, reeducação alimentar, alimentação saudável. Não sou nenhum expert no assunto, mas me preocupo com o que como. Minha esposa tb é bem preocupada com a alimentação da nossa família, sempre buscando uma alimentação saudável e balanceada. Para o ContaCal eu precisava de uma lista de alimentos com quantidade de calorias e a informação sobre a qualidade dessas calorias (calorias verdes, amarelas ou vermelhas). As cores servem para indicar quão recomendável é ingerir o alimento. Se é um alimento de calorias vermelhas, é melhor evitá-lo ao máximo. Calorias amarelas podem ser ingeridas com moderação. Já as calorias verdes podem ser ingeridas sem restrição. Como sugestão, no ContaCal recomendamos seguir a seguinte regra, não mais que 10% de calorias vermelhas, não mais que 35% de calorias amarelas e pelo menos 55% de calorias verdes. Para poder fazer a classificação dos alimentos, era necessário ter a ajuda de uma nutricionista, por isso, contratei uma para revisar uma tabela que montei a partir de dados que encontrei na internet.

Custo de terceirização

O custo total de terceirização foi de R$ 6090,00 sendo:

  • logo: R$ 500,00
  • template: R$ 50,00
  • ajustes no template: R$ 130,00
  • StartupDEV: R$ 4.800,00
  • Nutricionista: R$ 600,00

Próximo post

No próximo post, que irei publicar semana que vem, vou falar sobre quanto tempo dedicar à startup e se dá para fazer uma startup sozinho.


O que vc achou desse exemplo? Que outras formas de terceirizar vc já viu?

Using checklists to deal with the unexpected

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.

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.

So next time you design a checklist, remember to include not only task checks but also communication checks.

Collaboration lessons from the marshmallow challenge


  • Groups of 4 people
  • 20 sticks of spaghetti
  • one yard of tape
  • one yard of string
  • a marshmallow

Time constrain: 18 minutes

Objective: tallest freestanding structure


  • Who consistently performs worst? Recent business school graduates
  • Who consistently performs well? Recent kindergarten school graduates. Not only the tallest but the most interesting structures.
  • Why kindergarten school graduates do better than business school graduates? First, none of the kids spent any time trying to be CEO of “Spaghetti Inc.”. Business students are trained to find the single right solution. Kindergarteners build prototypes several times, get instant feedback of what work and what doesn’t and refine.
  • The very best group? Architects and engineers, thankfully!
  • CEOs with an executive admin perform significantly better than just CEOs. Why? Because they have special skills of facilitation. They manage the process.
  • Specialized Skills + Facilitation Skills = Success!
  • Incentives + Low Skills = no success.
  • Incentives + High Skill = Success!
  • Every project has its own marshmallow.
  • Shared Experience + Common Language + Prototyping & Facilitation
  • Sometimes a little prototype is all it takes to transform an Oh-Oh moment into a Ta-Da moment!


Qual a diferença entre gerir um projeto e gerir um produto?

Nos meus posts recentes sobre acompanhamento de projetos ágeis e o uso de burnups acabei me deparando com algumas questões mais “filosóficas” sobre produtos, projetos, gestão de produtos e de projetos e os papéis de PO (product owner) e scrum master nas metodologias ágeis.

Projetos e produtos

Projetos e produtos


Primeiro algumas definições básicas:

A project in business and science is a collaborative enterprise, frequently involving research or design, that is carefully planned to achieve a particular aim.


The noun product is defined as a “thing produced by labor or effort” or the “result of an act or a process”, and stems from the verb produce, from the Latin prōdūce(re) ‘(to) lead or bring forth’.


Ou seja, enquanto o projeto é um processo com começo, meio e fim, o produto é o resultado de um processo, de um esforço.

Então gerir projetos e gerir produtos são duas funções distintas?

Parece que sim. Enquanto se está gerindo um projeto, a preocupação é com o processo e com tudo o que o cerca, ou seja, se está no prazo, se tem os recursos necessários e se está sendo feito conforme esperado (qualidade e escopo).

Por outro lado, quando se gere um produto, a maior preocupação é, ou pelo menos deveria ser, garantir que produto resolve um problema do cliente a quem esse produto é destinado.

Em um post de 2007 do blog How To Be A Good Product Manager, o autor Jeff Lash lembra alguns pontos importantes que não devemos esquecer quando pensamos em gestão de projetos e gestão de produtos:

  • Just like every product needs a product manager, every project needs a project manager.
  • Just because product managers think they can manage their own projects does not mean they should.
  • The skills, talents, and traits involved in project management are very different from those involved in product management.
  • Just like it is hard to find one single person who can fill the product management role and the product marketing role, it is hard to find one person who can be successful at both the product management and the project management role.
  • Project management is not a stepping stone to product management, nor vice versa.
  • Good project managers are just as valuable as good product managers.
  • Finding a good project manager to manage your projects will help you be an even better product manager.
  • The less time product managers spend on project management, the more time they will be able to spend on product management.
  • To avoid conflicts between product management and project management, product managers, project managers, and project teams should all agree on shared goals and objectives as much as possible.

Marty Cagan deixa claro a necessidade de separação desses papéis em um de seus posts:

For Internet services companies, it really is important that the roles be separate. You’ll thrash in release management if you don’t, and releases will consistently be delayed and take longer than they should.

E como as metodologias ágeis vêem essas funções?

As metodologias ágeis, mais especifcamente o Scrum, tem dois papéis claros no time, um focado mais no projeto, o Scrum Master e outro focado mais no produto, o Product Owner (PO):

[Scrum] Roles:

Product Owner: The person responsible for maintaining the Product Backlog by representing the interests of the stakeholders.
ScrumMaster: The person responsible for the Scrum process, making sure it is used correctly and maximizing its benefits.
Team: A cross-functional group of people responsible for managing itself to develop the product.
Scrum Team: Product Owner, ScrumMaster and Team


Há um artigo na InfoQ com o título “Can Product Owner and Scrum Master be Combined?” em que o tema de ter um única pessoa gerindo projeto e produto é discutido. Tanto nas opiniões que compõem o texto e que incluem testemunhos de pessoas como Mike Cohn e Ken Schwaber, quanto nos comentários do texto é unânime que apesar de ser possível combinar as duas funções e, se o time for muito pequeno, ser até aceitável, o mais recomendado é que essas funções sejam desempenhadas por pessoas diferentes.


  • Gerir um projeto é garantir que o processo está fluindo da melhor forma possível, dentro do prazo, com os recursos disponíveis e atingindo os objetivos de escopo e qualidade definidos. Ou seja, gerir projetos é olhar para dentro da organização.
  • Gerir um produto é garantir que o resultado de um processo satisfaça as necessidades do cliente. Ou seja, gerir produtos é olhar para fora da organização.
  • É possível e, se o time for muito pequeno (até 5 pessoas), pode ser até aceitável combinar as duas funções. Contudo, o mais recomendado é que essas funções sejam desempenhadas por pessoas diferentes.