What Developers should know about Product Management
Learning about business perspective can improve technical decisions that developers need to take on a day-to-day basis.
Life as a developer
I started my career working in a startup as a developer. I had a really good manager. For 2 years, he taught me to write maintainable code, create a scalable architecture and write tests to ensure quality.
It would have been the best job in the world... If it wasn’t because of product managers.
Product managers were cold terrible people. They did not care about quality, efficiency or maintenance. They just wanted us to finish a project as fast as possible.
I remember one of them skipped the design of a feature and gave it to us to deliver it faster… it was the ugliest feature I have ever seen.
I really loved my job, but Product managers brought all the bad: stress, deadlines, tech debt, etc.
I hated writing low-quality code, so I decided to try in a new company.
Spoiler alert: it did not improve.
Actually, it got really bad. I started to work in a team with two product managers. I am going to call them Bob and Alice. On a normal day, I would have a list of ten bugs that needed to be fixed. I would pick issue 1111. Then, Alice would come and ask me to finish issue 3003 first. Then we would have the standup, where Bob would say that ticket 6676 was the top priority… COULD THEY TALK TO EACH OTHER BEFORE TALKING TO US?
That was when I moved to DevOps.
Learning about business
In DevOps, there are no product managers. So I went from having two to having zero!
Awesome right? Best job ever, I got to write code and enjoy life! But with the new role, I got new responsibilities too: investigate what Developers need, calculate budgets, design new tools, create and analyze metrics, risk analysis… We had no product managers because we were the product managers!
Developers were our customers and we were trying to release new value to them. This made me change my point of view about product managers.
I want to tell you the story of two projects that taught me many lessons:
The first story is when we released a new feature called Parallel Deployments. We put lots of effort and thoughts into it. Then we rolled it out as an optional feature… and people loved it. We got feedback and it was awesome. Everyone was using it so it became a de-facto way to deploy.
This taught me how satisfying it is to fix a problem that your customer is facing. It gave me a sense of self-realization.
The second story is when we woke up one day and our testing cluster did not work. Most Developers were blocked in their work: releases, deadlines, and testing were all paralysed. We needed a fast fix.
We worked 6h straight (no lunch break) to create a new full working environment (did I mention that it was in a different Cloud Platform?). It was a huge effort! We did some manual changes and ugly patches. I’m not proud of it… but we got it working!
It was then when I started to understand Product Managers and why some times having technical debt is not the worst.
After that, I read some books about Product Management: Project to Product by Mik Kersten, Inspired by Martin Cagan. I also read some business books like The Lean Startup by Eric Ries.
Now that I understand some of these business values, I don’t see Product Managers as awful monsters anymore. They are people responsible to bring value to customers.
The problem is that most companies have a wall between business and development that hide all this valuable information. As a developer, every ticket looks the same. I don’t know what brings value to customers, so it’s difficult to make decisions between quality, efficiency, scalability and time spent. And I get pissed off if they ask me to release a low-quality feature because of an unreasonable deadline.
I want to share with you some of the things that I learned about business. So you can help to break the wall between Engineering and Business and have more meaningful work.
Business values
These are the most important things that I learned from these business books and my own experience:
Why do we work
Success is not delivering a feature; success is learning how to solve the customer’s problem
— Eric Ries
A Product is bigger than engineering. It starts when someone thinks about that feature. Then prioritization, planning, and design are needed. Depending on the company, many more steps may be part of this value stream. Probably, when you see a new feature ticket in your board, it has already been in many others teams’ boards for months.
In engineering, we make trade-offs between efficiency, quality, time spent and maintainability every day. To take the best decisions, we should aim to understand the main parts of this value stream and the customers’ needs.
The problem is that business people and engineers use different languages. As an engineer, I like facts: how fast do I fix a bug (maintainability), coverage in my tests (quality), how fast do I add a new feature (tech debt), error rate (quality), availability of my system(stability),… But I have no idea about business metrics! I just see priorities that have no explanations.
In Mik Kersten’s book called Project to Product, he defines a Flow Framework to correlate business results (Value, Cost, Quality and Happiness) with development metrics (Velocity, Efficiency, Time and Load). This not also helps developers take better decisions, but it also helps business people define a better strategy for the company.
In his book, Mik Kersten also discusses the importance of traceability on a Value Stream Network. Software development looks like an interconnected network of teams where each of them adds value to the product. The problem is when work arrives at the team more like a dump than a traceable story (what is the customer that needs the feature, when was designed, which work has been done by which teams,…).
How should we work
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software
— First Principle of the Agile Manifesto
No one knows about the future. The best thing we can do is to add a small change, get feedback and LEARN. This improves the capacity of adaptability to the team and will allow adapting to market trends quicker than the competition.
Small changes are useful everywhere:
- as a Developer, it is better to add small pieces of code that can be easily reviewed and tested.
- as a DevOps, it’s better to test a new tool in a small set of developers first and get feedback before using it everywhere.
- as a Product Managers, it helps to test hypotheses about the users. I once released a feature that took a month to build, just to see that no customer used it. The quickest we can test if it makes sense to build a feature, the better. This is called an MVP (minimum viable product) and it’s used to reduce time wasted on unneeded features.
Who is responsible for the business
Specialization allows us to handle ever-growing complexity, but the benefits of specialization can only be fully realized if the silos that it creates can be connected effectively.
— Mik Kersten
People run companies. They define culture and are responsible for every desition made. That is why communication is highly important.
In the book called The Five Dysfunctions of a Team by Patrick M. Lencioni, he shows a pyramid of what makes a team dysfunctional. I believe these principles can be applied to fix communication problems: they can be used on something as small as within a team, to collaboration between teams or even between two companies.
From bottom to top, these dysfunctions are:
- Absence of TRUST. Teammates need to be vulnerable with one another. It is vital to have confidence among team members to know their peers’ intentions are good and that there is no reason to be protective.
- Fear of CONFLICT. Conflict helps growth, producing the best possible solution in the shortest period of time. Adding light to disagreements and force members to work through it is key to resolve issues.
- Lack of COMMITMENT. Some times it feels that a difficult decision gets delayed all the time. This is due to a lack of clarity and lack of buy-in. You should keep clear that a decision is better than no decision. Even a wrong decision can help us continue and learn from our mistakes.
- Avoidance of ACCOUNTABILITY. Team members should be willing to call their peers on performance or behaviours that may hurt the team. If there is a specific process or requirement, everyone in the team should enforce it and ask others to follow it. Here, regular reviews and team rewards can help to achieve it.
- Inattention to RESULTS. This is when we avoid team status to focus on individual status. Teamwork is more important than superheroes. When I see a single person is responsible for the efficiency of a team.. I get scared. I have seen this many times: there are no discussions or communication as this person takes all the decisions alone. To avoid it, there should be a Public Declaration of Results and leaders should show that they do not value anything more than results.
Thanks for reading!
Maybe you are like me and have had bad experiences with Product Managers. If so, just try to talk to them and ask for metrics and information about customers. I have to say that the product managers I talked about were good at their job, but we did not know how to communicate.
Leave a comment and applause if you liked this blog post. You can also write me on my twitter account @Marvalcam1
