In April this year, I gave a talk on the journey of our team at Siemens from being completely new to being a full-fledged product team here. One of the topics that I delved in, and which I believe in, is the difference between a Software Team and a Product Team. I’m going deeper into the differences in the following article.
India has excelled phenomenally in the field of Information Technology. But generally, our role has been limited to being a software team where we work on the given requirements and deliver the code. But we don’t get credit in the market for the product. We don’t own the success or failure of the product. I feel that to move to the next level in ownership, we need to start working as Product teams. The below points can also act as a roadmap for the shift.
I’m presenting some caveats so that the context of the articles and the limitations are set.
Caveat #1: In the articles, I’m going to present the advantages of a Product team. But I do not want to disparage the Software teams. It has its own set of strengths and weaknesses.
Caveat #2: A lot of the points presented are contextual to what I’ve observed in my career in India and may not be relevant across the globe.
Caveat #3: When I say a software team, I don’t mean teams in software or services companies. The differences between these teams stems from what drives them, and their core principles. There can be a product team in a services company, and a software team in a product company.
- “Why should this product exist?”
As developers, testers or project managers, we tend to focus on the final deliverable, which is usually the next release, or delivery, or milestone. The team has to deliver the code, binaries, documentation, and other artifacts needed as part of the release. The team works hard to ensure that all the metrics and KPIs are achieved. The developers receive the requirements and they ensure that all the requirements are met. The testers also ensure that they have found as many bugs as possible and got them rectified before the final release. The project manager monitors and tracks the process and documents every step.
At the end, the team does an extraordinary job, sometimes under pressure of delivery or management. They work as a team and achieve a milestone that some thought impossible.
But … the product didn’t make it to the market!
How many times have we been in such situations? We ask ourselves (or at least should ask) what went wrong. Whose fault was it? Was it the project manager’s fault? Or developers’ fault? Or testers’ fault? Or was it the Product Manager who should’ve come up with better requirements or done a better research?
Instead of assigning blame, we need to ask, “How we could’ve prevented this?” I know that the team alone could not have prevented the failure. There are other factors at play here, but I’m going to focus on the role of the team.
As a software team, our job is to finish the deliveries. When a contract is signed between the company asking for the product and the company developing it, both parties agree upon a set of deliverables, quality and budget. (You could substitute ‘company’ with ‘divisions’, ‘business units’ and still have the same situation.) The development team focus remains the deliverables. The project manager, once having taken on the project, has to ensure that the costs remains within the budget, deliveries are on time and with the agreed-upon quality.
But the team doesn’t ask the rationale of the product. No one asks the questions: “Is this product needed?”. If yes, then are we even building for the right people?
These questions are critical for a product to be successful. The product manager, the higher management need to provide the raison d’être for the product. A product team asks these questions and ensures that they are answered to their satisfaction. Many times, they also provide the answers themselves. Once it has the answer, then it believes in the product and is driven by the passion for the product.
But if the team isn’t satisfied by what they hear from the management, then they must be empowered to call a stop to the product.
- What is your Passion?
About 10 or 12 years ago, I wrote a function for my project, that contained nearly hundred string compares (and this was a C code), to determine the exact property of the input. The function behaved like switch-case for strings. I wanted to optimize it, so I came up with an algorithm that would, at least theoretically, do the same operation in much lesser time. I was very proud of the algorithm and its implementation. The function was efficient when executed.
But the overall impact was much less as it wasn’t executed that often. I was too focused on the code, and missed the fact that it didn’t deliver much value.
I’ve seen the above scenario lot of times. The developers are proud of the code that they have written, the various optimizations and algorithms that they have used. Their code is beautiful, and follows all the coding guidelines. The testers are proud of the automation tests, the complex scenarios they have tested, the reports showing how many bugs they discovered. The project manager is proud that the project achieved the scope, was within budget, and was able to deliver on time. He or she created complex Excel reports, beautiful Powerpoint presentations to showcase their achievements, and diligently documented every step of the project.
Members of software team are too focused on their area of expertise. Their pride stems from their brilliance on the code, testing, sometimes even just the beautiful drawings that they have created for the project. They look for brilliant solutions, not necessarily the simplest ones.
A product team, on the other hand, is not driven by the code or test cases or algorithms. It is driven by the product – the problems it solves, the value that it provides to clients or end users. A complex code, if it doesn’t add any value, is not exciting enough. On the other hand, a simple function that solves a bigger problem generates more enthusiasm in the team.
Another passion of a software team is Design. I’ve heard many developers, architects, testers defend a design and say that a feature cannot be implemented because it does not fit in the design. They are in love with the design, which was created after a significant effort in the early phases of the product.
However, for a product team, the feature takes precedence. There are some practical limitations for feature implementation, such as efforts needed and if they fit in the roadmap. But the feature trumps design considerations. Once the team agrees that the feature is needed for the customers and understands the rationale, they go ahead and develop it.
- ‘ “I do not love the bright sword for its sharpness, nor the arrow for its swiftness, nor the warrior for his glory. I love only that which they defend.” said Captain Faramir’
The above quote is taken from the book ‘The Two Towers’, of the Lord of the Rings trilogy, by J.R.R. Tolkien. It can be modified for software context as “I do not love C for its effectiveness, nor Java for the object-oriented methodology, nor python for its ease of coding. I love only that which they deliver.”
Developers and testers are focused on the technology, or the language or the tools that we use. I understand that in the beginning of the career of any software engineer, she or he wants to work on languages or technology that has the highest salary potential. However, such people also want to move to the latest language because it is in vogue. I’ve heard many people in the Indian IT industry that they want to work on the latest technology. Developers want to work on latest version of Java, or take up languages or frameworks like Golang, Angular JS, Django, Flask, etc. or take up new technologies such as Machine Learning, Artificial intelligence. A few months back an engineer rejected our interview call because we aren’t working on latest version of Java; he wasn’t even interested to know about the product or the domain. I heard of another interview, where the candidate actually tried to convince the interviewer to change the current bug tracking tool to one that the candidate is more comfortable with.
Our interviews processes too are language or tech oriented. Interviewers ask about what she has worked on, or the intricacies of a chosen language. They judge the candidates on how much the person knows about the language. This is a legitimate method to determine if the candidate has good hands-on experience, but that is also a limited view of the candidate. This process doesn’t tell us whether she can deliver in our projects or how she can handle unknown scenarios. We should, instead, look for people who can learn quickly and adapt, and are able to solve problems. We hardly ever try to judge people on such skills.
A Product team on the other hand learns and adapts to whatever tools/technology/language solves their problem. I’ll explain with an example. We have a spreadsheet/table implementation in my current product. However, it has its limitations, and we are trying to solve the issues that arise due to the limitations. My team quickly moved to SQLite as the backend for the table to try and solve the problem. Instead of trying to solve the problem using the current language (C++/QT) only, they quickly moved to integrate SQLite. A Product team has high adaptability and learning skills. Their aim is to deliver the product using any tools available.