Engenharia de produtos e gestão de produtos

Estava relendo alguns posts e quando li o último post da série sobre diversificação de portfólio de produtos lembrei que fiz promessa de dois posts, um sobre a relação de UX e gestão de produtos e outro sobre a relação de engenharia e gestão de produtos. Como promessa é dívida, está na hora de pagar as minhas dívidas. Vou começar falando sobre a relação entre engenharia de produto e gestão de produtos.

engineering

Definição

Engenharia de produto é responsável por desenvolver o produto e mantê-lo operando. Com a visão de negócios trazida pelo gestor de produto, mais o desenho de solução feito pelo pessoal de UX, baseado no entendimento da necessidade ou do problema do cliente, a engenharia de produto “constrói” o produto. Para construir o produto ela deve não só fazer a programação, como também definir a arquitetura técnica do produto, ou seja, qual é a infra-estrutura onde vai rodar esse produto, qual a linguagem de programação mais adequada, qual o banco de dados mais apropriado, como garantir os requisitos não funcionais desse produto (velocidade de resposta, disponibilidade, escalabilidade, etc). Deve tb validar com o gestor de produtos se o custo dessa infra-estrutura cabe no modelo de negócio desse produto.

gp

Pelo fato de o gestor de produto ser responsável por definir o produto a ser feito, pode dar a impressão que a engenharia de produtos está subordinada à gestão de produtos, mas essa visão é incorreta e, se as áreas se comportarem dessa forma, a chance de fracasso do produto aumenta, pois quem se sente subordinado tem menos comprometimento com o resultado. Engenharia de produtos, gestão de produtos e UX são pares, não há relação subordinação entre nenhum desses grupos. Eles devem funcionar como parceiros, como sócios, cada um com sua especialidade e com sua responsabilidade, colaborando para produzir o melhor produto possível.

Inovação

No diagrama acima a engenharia de produtos é quem traz a tecnologia disponível. Certa vez vi uma definição interessante sobre inovação. Inovar não é simplesmente conhecer a última tecnologia. É preciso conhecer não só a última tecnologia, como também todas as tecnologias disponíveis e saber como usá-las. Esse é o papel da engenharia de produtos. Conhecer as tecnologias disponíveis e saber como usá-las para resolver um problema ou atender a uma necessidade de um grupo de pessoas é o que tem potencial de produzir uma inovação.

Dicas práticas para gestores de produto

Para facilitar o dia-a-dia com o time de engenharia de produto, aqui vão algumas dicas práticas:

  • Não se meta na solução técnica, a não ser que vc tenha conquistado o direito de se meter nas soluções técnicas. Um gestor de produto deve ter algum conhecimento técnico sobre seu produto, mas essa não é sua área de especialidade. Os especialistas estão na equipe de engenharia de produto. Por isso, evite apresentar soluções técnicas para o time de engenharia de produto a não ser que esse time te dê abertura para isso.
     
  • Leve engenheiros nas conversas com clientes e usuários. Como parte do seu dia-a-dia como gestor de produto, vc deve conversar sempre com os clientes e usuários de seu produto para entender como seu produto resolve o problema ou atende à necessidade desse seu cliente ou usuário e como vc pode fazer seu produto ainda melhor. Os engenheiros gostam muito de ir a essas conversas. É uma experiência única quando eles vêem pessoas reais usando um software que eles desenvolveram. Eles ficarão ainda mais engajados na missão de fazer um produto melhor.
     
  • Sempre tome decisões baseadas em dados. Quer seja dados de acesso e de uso do produto, quer seja dados de conversas com clientes e usuários, use dados para tomar suas decisões e apresente esses dados para o time. Isso dará maior consistência às histórias que vc irá colocar no roadmap do seu produto.
     
  • Aprenda a tirar o excesso, busque sempre o produto mínimo ou a funcionalidade mínima, ou seja, procure implementar o mínimo possível para atingir o seu objetivo denegócio.
     
  • Esteja presente. É fundamental estar junto com o time de engenharia de produto ou, pelo menos, acessível ao time o máximo de tempo possível. Durante o desenvolvimento do produto inevitavelmente surgirão dúvidas e, se vc não estiver presente, ou o time para, ou o time vai implementar como eles acham que deve ser, o que pode ser diferente do que vc havia planejado.
     
  • Dê feedback para time sobre o produto. Vc, como gestor de produto, sabe como o seu produto está indo, quantos usuários tem, o que esses usuários estão achando do produto, como esse produto está ajudando a empresa a atingir seus objetivos. Conte periodicamente sobre isso para o time de engenharia de produto. Como isso vc estará dando um contexto e um propósito para o time.
     
  • Negocie as histórias de reescrita e de manutenção. O time de engenharia, se for um bom time, antenado na evolução das boas práticas de engenharia de software, sempre irá descobrir formas melhores de implementar cada pedaço do produto. A depender do time de engenharia, o backlog do produto só teria histórias de melhoria técnica. Isso é bom, mostra que vc está trabalhando com um ótimo time de engenharia. Contudo, vc deve usar o item anterior para dar o contexto do produto para o time, ou seja, mostrar que há determinados objetivos definidos para produto que vcs tem que atingir e que, por isso, vcs devem sempre colocar novas funcionalidades no produto. Deve existir um balanço entre histórias de manutenção e reescrita e de novas funcionalidades. Já li em vários lugares algo como defina X% do tempo para histórias de manutenção e reescrita. Eu não gosto de dar essa sugestão, pois acredito que cada momento do produto requer equilíbrio diferente e cabe ao gestor de produto e ao time de engenharia de produto conversar e definir de comum acordo esse equilíbrio apropriado a cada fase do produto. Vale lembrar da importância de encontrar um bom equilíbrio, pois isso evitará o famoso débito técnico que, à medida que cresce, fará com que o time de engenharia de produto fique cada vez mais lento.
     

Ah, e tem mais um ponto!

Alguns engenheiros de produto acabam se tornando ótimos gestores de produto. É importante ser capaz de perceber quando um engenheiro está procurando “outra coisa pra fazer” e dar a ele essa opção de carreira. Na Locaweb temos e tivemos ótimos gestores de produto que eram engenheiros de produto. Em alguns casos acabaram se tornando gestor de produto do próprio produto em que era engenheiro. Por outro lado, existem alguns engenheiros de produto que experimentam a gestão de produtos e não gostam. É preciso deixar a porta aberta para ele poder voltar a ser engenheiro de produto, sem nenhum prejuízo para a sua carreira.

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:

IT-project

dilbert

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?

Dica de arquitetura de sistemas para startups

A dica rápida de hoje é sobre arquitetura de sistemas. Semana passada o Rachad, gerente de engenharia dos produtos SaaS da Locaweb, apresentou para as startups que estão sendo aceleradas na Aceleratech algumas dicas sobre arquitetura de sistemas para startups:

E para facilitar sua vida, não se esqueça do Jelastic Cloud Locaweb.

jelastic_cloud_locaweb

É um PaaS (Platform as a Service), tipo Heroku e Google App Engine.

Roda aplicações Java e PHP. Vai ter Ruby no início de 2014. Tem várias opções de banco de dados, Postgres, MySQL, MariaDB, Mongo e CouchDB. Tem auto scaling tanto vertical como horizontal. É cobrado por hora e é mais barato que Amazon, e bem mais barato que Heroku e Google App Engine!

Para experimentar sem custo essa super novidade, basta acessar:

http://Locaweb.com.br/Jelastic

É uma ótima solução para infraestrutura de startups.

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.

Why before how

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.

Quanto tempo levou para fazer o ContaCal?

Já falei aqui como fiz o ContaCal. Para confirmar a importância de fazer rápido o produto web, aqui está um gráfico que mostra quanto tempo levei para colocar o ContaCal na frente de clientes:

Dados do desenvolvimento e lançamento do ContaCal

Dados do desenvolvimento e lançamento do ContaCal

Cronograma:

  • 23/08/2011: Início do desenvolvimento da aplicação pelo pessoal da StartupDev.
  • 25/08/2011: Aplicação pronta e início da adaptação do logo e do template de WordPress.
  • 01/09/2011: Site em WordPress pronto.
  • 02/09/2011: Campanha de AdWords religada. Até aqui eu só tinha usuário de teste. A partir daqui é o momento da verdade, com usuários reais utilizando o sitema.
  • 04/09/2011: Email para pessoas que mostraram interesse.
  • 07/09/2011: Início de campnha no Facebook.

Ou seja, do início do desenvolvimento até religar a campanha no AdWords foram 10 dias! 🙂

Resultado

Veja nas telas abaixo a primeira versão do site e da aplicação. Ambos já mudaram significativamente desde essa primeira versão.


Primeira versão do site

Primeira versão do site

Primeira versão da tela de login

Primeira versão da tela de signup

Primeira versão do produto web

Primeira versão do produto web


Boas práticas de engenharia de software

Claro que não adianta você saber exatamente o que vai fazer na versão mínima de seu produto web se você não tiver um ótimo time de desenvolvedores de software e designers de interface do usuário. Só que ter pessoas bem qualificadas por si só não resolve. É preciso que essas pessoas trabalhem usando as melhores práticas de engenharia de software. Vou comentar um pouco sobre algumas dessas práticas aqui, apesar de esse não ser o foco principal deste blog.

Desenvolvimento iterativo de software

A primeira boa prática que quero comentar aqui é o desenvolvimento iterativo de software. Essa forma de desenvolvimento se contrapõe ao modelo de desenvolvimento de software conhecido como waterfall. No desenvolvimento waterfall as fases de desenvolvimento de software são claramente definidas e, uma vez terminada uma fase e iniciada a outra, não se pode voltar atrás. Por exemplo, se você quer desenvolver um produto web, no desenvolvimento waterfall você precisa especificar absolutamente todas as funcionalidade que você vai querer nesse software, pois o desenvolvimento de software é visto como um projeto com começo, meio e fim que acontece em sequência: definição de requisitos, detalhamento e especificação do software, codificação, teste e produção. Já no desenvolvimento iterativo de software, esse mesmo ciclo é reduzido ao seu menor tamanho possível e repetido várias vezes usando o feedback do ciclo anterior para melhorar o próximo ciclo.

Jeff Patton, reconhecido consultor de desenvolvimento de software, fez uma comparação entre waterfall e desenvolvimento iterativo de software fazendo uma analogia com o processo de pintar um quadro. Qual dos dois processos abaixo parece ser mais natural?

Waterfall

Waterfall

Desenvolvimento iterativo

Desenvolvimento iterativo

Esse processo de desenvolvimento iterativo de software acabou sendo uma das bases do Manifesto para Desenvolvimento Ágil de Software, escrito há mais de 10 anos, que acabou se tornando uma revolução na forma de se fazer software:

Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmos e ajudando outros a fazerem o mesmo. Através deste trabalho, passamos a valorizar:

  • Indivíduos e interações mais que processos e ferramentas
  • Software em funcionamento mais que documentação abrangente
  • Colaboração com o cliente mais que negociação de contratos
  • Responder a mudanças mais que seguir um plano

Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.

Esse manifesto melhorou em muito a forma como software é desenvolvido, garantindo maior envolvimento da pessoa que define como vai ser o software durante o desenvolvimento desse software.

A partir desse manifesto alguns processos de desenvolvimento de software foram criados de forma a permitir esse envolvimento. Uma das recomendações que veio como consequência do manifesto é os times que desenvolvem software devem se reunir periodicamente para definir o que fazer e para acompanhar o andamento do projeto. Nessas reuniões participam não só os desenvolvedores de software como também as pessoas que definem “o que” e “como” será o produto web. O “o que” é definido pela função de gestão de produto e o “como” é definido pela função de experiência do usuário, funções descritas no post Quem deve criar uma startup de um produto web?. Essas reuniões frequentes são fundamentais para garantir a velocidade de entrega do produto mínimo.

TDD

Outra boa prática muito importante é o TDD (Test Driven Development ou Desenvolvimento Baseado em Testes). Por meio dessa prática se garante não só a qualidade do software que está sendo desenvolvido, uma vez que todas as suas funções têm testes para garantir que o que foi desenvolvido está funcionando conforme esperado, testes esses preferencialmente automatizados, como também aumenta a segurança para futuras modificações nesse software. Quando seu software tem testes, você pode adicionar novas funcionalidades e, por meio dos testes, garantir que o software continue se comportando conforme esperado em todas as situações previstas e cobertas pelos testes.

Entrega contínua

Ter essa cobertura de testes é fundamental para poder executar a terceira boa prática que eu queria comentar, a entrega contínua. Entregar continuamente o software significa ter a capacidade de colocar seu software em produção a qualquer momento de forma simples. Você só poderá fazer isso se:

  • tiver cobertura de testes para garantir que o software que você colocou em produção está fazendo o que se espera dele e;
  • tiver uma forma simples e rápida de voltar atrás, ou seja, se der algum problema com o software que você acabou de colocar em produção, você é capaz de restaurar a versão anterior do seu software em produção.

Ter entrega contínua é muito importante para que você possa, após ter seu produto web funcionando e com usuários, fazer rapidamente modificações nesse seu produto web baseado nos feedbacks que você receber desses usuários.

Como disse acima, quis incluir aqui no blog um rápido comentário sobre as boas práticas de desenvolvimento de software mas eu recomendo que, caso você não tenha ouvido falar dessas práticas, procure conhecer mais lendo blogs, indo a cursos, lendo livros e participando de eventos sobre desenvolvimento de software.

Recapitulando: fazer rápido o produto web = saber o que fazer + boas prática de engenharia de software

Por melhores que sejam os desenvolvedores e os designers de interface que trabalharem no seu produto, se você não escolher com muito cuidado que funcionalidades colocar e não selecionar um conjunto mínimo de funcionalidades, as chances de você desperdiçar tempo de desenvolvimento são muito grandes. A definição clara de seu produto mínimo é fundamental, e você só vai conseguir fazer isso conhecendo bem o problema do seu cliente e sabendo exatamente o que você está resolvendo para ele. Além disso, mesmo os melhores profissionais com a mais clara definição do que vão fazer precisam de boas práticas de desenvolvimento de software para poder desenvolver com rapidez um produto web de qualidade.

You need to talk with real users in order to build good software

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.

  • Product Management role tells what needs to done and in what order.
  • Experience Design role tells how what needs to done should be done, from the user experience perspective.

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! 🙂

Como fazer rápido o seu produto web?

Já entendemos porque é importante fazer rápido o produto web. Agora precisamos saber como fazer isso! Será que precisaremos de bons desenvolvedores de software? Com certeza. E bons designers de interface do usuário? Sem dúvida alguma!

Contudo, só ter bons profissionais te ajudando não é o segredo para vc fazer o produto rapidamente. O que você precisa fazer é definir quais são as funcionalidades mínimas necessárias para o seu produto. Esse é a principal responsabilidade da função de gestão de produtos que, como eu comentei anteriormente no post sobre as diferentes áreas de conhecimento envolvidas em uma startup, é uma das únicas funções que não podem ser terceirizadas. Quem tem que fazer isso é vc.

A importância de conhecer o cliente e o seu problema

Nesse momento fica claro a importância de se conhecer muito bem o cliente e o seu problema. Vc vai ter que entender muito bem qual é o problema e qual é a solução mínima que vai resolver o problema desse cliente. Fica claro também a vantagem de se trabalhar em um problema próprio, pois sendo vc mesmo o cliente, é mais fácil definir o que é mínimo para resolver o problema.

Tome cuidado pois, como com software dá para fazer muitas coisas legais, é muito fácil a gente cair na tentação de querer colocar “só mais essa funcionalidade” antes de lançar o produto. Pense bastante se essa funcionalidade não terá um custo muito alto de desenvolvimento em termos de tempo, energia e dinheiro – vc se lembra das curvas de retorno de investimento do post anterior? – para o benefício que ela pode trazer para a solução do problema do cliente.

Para ilustrar isso de forma clara, vou citar dois exemplos.

Cursos online da Caelum

A Caelum é uma empresa bastante conhecida pelos seus cursos presenciais de desenvolvimento de software. Há uns 3 anos começou a surgir demanda por cursos online mas Paulo e Guilherme Silveira, sempre preocupados com a qualidade de ensino, não queriam dar esse passo até encontrar uma forma de oferecer cursos online com uma qualidade satisfatória. No início de 2011 encontraram um formato que lhes pareceu interessante. Resolveram então desenvolver o produto web de educação online com esse formato. O desenvolvimento começou em fevereiro de 2011 e a versão para usuários gratuitos ficou pronta no final de julho de 2011, totalizando 5 meses de desenvolvimento. Paulo ainda estava inseguro quanto a lançar na QCon em setembro, sentia que ainda precisava colocar várias funcionalidades, dentre elas a cobrança. Eles correram para colocar alguma forma de cobrança que ficou pronta literalmente no dia do lançamento que foi no primeiro dia da QCon. Várias funcionalidades que eles queriam ter colocado para o lançamento da versão paga acabou não entrando no lançamento.

Resultado: o primeiro cliente pagante veio somente depois de duas semanas, ou seja, a cobrança não era tão necessária para o lançamento. Agora em março de 2012, é uma funcionalidade bem necessária! Já são quase 130 cursos vendidos e um total de 400 alunos distintos. Contudo, a cobrança poderia ter sido desenvolvida após o lançamento. As outras funcionalidades que eles queriam ter colocado não fizeram falta para o lançamento do produto e, quando houve clientes reais utilizando, o que esses clientes deram de retorno acabou orientando o desenvolvimento do produto web.

ContaCal

Quando usei o pessoal da StartupDEV para fazer o ContaCal, eu não tive a opção de tentar fazer mais desenvolvimento e gastar mais tempo, eu tinha direito a apenas 48 horas. Eu mostrei para o time de desenvolvedores o que eu queria e eles estimaram quanto tempo cada pedaço do sistema ia levar. Obviamente que fazer todo o sistema ia ultrapassar as 48 horas que eu tinha direito, então tive que escolher.

Quando desenhei os wireframes do ContaCal para passar para o pessoal da StartupDEV desenvolver a aplicação web, os slides 4 e 5 tinham dois gráficos, uma para mostrar a evolução das calorias e outro para mostrar a evolução do peso. Não tinha como caber os dois. Eu tinha que escolher um dos dois, ou gráfico de evolução de calorias, ou gráfico de peso. Lembro que foi uma decisão difícil, e depois ainda conversamos sobre fazer versão de 7 dias e versão de 30 dias.

Decidi por implementar o relatório com evolução de controle de calorias, com visualização de 7 dias e 30 dias. Recebo com alguma frequência pedido de clientes que gostariam de ter alguma forma de acompanhar seu peso no contaCal. É a funcionalidade que deixei de implementar. Por outro lado, de todos os pageviews que a aplicação tem, 4,6% são pageviews dessa funcionalidade, ou seja, uma funcionalidade que tem um uso razoável, ainda mais comparado com 31,4% de pageviwes da página principal da aplicação:

Pageviews do ContaCal

Pageviews do ContaCal

Só que a dúvida ficou, será que relatório era de fato uma funcionalidade essencial para ter numa versão mínima do produto? Será que as pessoas gostam mais do produto por ter essa funcionalidade. Tem algumas formas de saber. Uma delas é fazendo uma pesquisa segmentada, ou seja, conversando com usuários que usam e com usuários que não usam a funcionalidade para saber dos que usam o que gostam e porque usam e dos que não usam, porque não. Outra forma é simplesmente desligando essa funcionalidade por algum tempo e ficando antenado para reclamações e comentários.

Minha opinião é que o ContaCal poderia ter sido lançado até mesmo sem a funcionalidade de relatório e que isso não teria impactado o número de usuários que se cadastram e que depois se tornam assinantes.

Falo isso devido a outra funcionalidade que implementei no ContaCal após o lançamento. Muitos usuários comentaram que seria muito bom ter a possibilidade de controlar não só a quantidade de calorias ingeridas como também a quantidade de calorias gastas. Em novembro, dois meses e meio após o lançamento, coloquei essa funcionalidade no ContaCal, de registro de atividades físicas. Anunciei para a base de usuários existentes, destaco isso como uma das funcionalidades que o sistema tem e várias pessoas acham bacana, mas a curva de novos usuários que se cadastram para testar o sistema, bem como de usuários que decidem virar assinantes não mudou em nada! Para confirmar, acabo de ver na base de dados que 1,8% dos registros feitos são de atividades, 98,2% são registro de alimentos.

Recapitulando: fazer rápido o produto web = saber o que fazer

Por melhores que sejam os desenvolvedores e os designers de interface que trabalharem no seu produto, se vc não escolher com muito cuidado que funcionalidades colocar e não selecionar um conjunto mínimo de funcionalidades, as chances de vc desperdiçar tempo de desenvolvimento são muito grandes. A definição clara de seu produto mínimo é fundamental, e vc só vai conseguir fazer isso conhecendo bem o problema do seu cliente e sabendo exatamente o que vc está resolvendo para ele.

Próximo post

O próximo post vai ser surpresa! Já tenho ele montado e ele tem por objetivo confirmar que é preciso lançar logo um produto. Só não vou contar como será o post para não estragar a surpresa! 😛

Comentários

Vc conhece algum exemplo de produto que, quando foi lançado, era mínimo mas já resolvia um problema de cliente? Compartilhe nos comentários.

What is Product Management?

DDD (Domain Driven Design) has a very powerful concept, so powerful that it is the first concept presented to anyone who is initiated in DDD, Ubiquitous Language:

A language structured around the domain model and used by all team members to connect all the activities of the team with the software.

source: http://domaindrivendesign.org/node/132

It’s a way to guarantee a shared understanding of the main terms used in a domain.

I’ll start to write more about Product Management here, so I felt the need to define Product Management prior to writing more about it.

Product

Prior to defining Product Management, let me define product in the software development industry:

Product is any customer facing software system.

A customer facing software system is not necessarily a system which drives revenue through subscription or on-demand use. A system like a newspaper portal can be considered a product. The revenue from such a system probably will come from ads. An internet banking is another example of a customer facing system who would benefit from product management. It doesn’t drive direct revenue but it helps decreasing cost of physical bank offices.

Product Management

And here goes the Product Management definition:

Product Management is accountable and responsible for everything from high-level objectives to the details of the user experience of a customer facing system. It’s the connection between the business strategy and the customer through a software system.