This year marks the 20th anniversary of the signing of the Agile Manifesto. It was a milestone that became a turning point for an entire industry. Today, twenty years later, I would like to comment on some things about it, but not about the agility and the manifesto (I think that much has already been saying about that) but about a divergent path that Product Management provides.
For that, I am going to go back to my first major challenge in Product Management. It began in mid-2003 and lasted until the end of 2006. Yes, a long time ago (it is not worth taking accounts!).
The product in question was called metaSAP and later ViaWise. It was a web solution that integrated with SAP and created copies of the screens and business rules to execute the processes from a browser (at that time Internet Explorer and Netscape) or a handheld with Windows ME. (I said it's not worth doing the math eh :)).
Thanks to this product, I had the opportunity to experience the difference between a delivery team, a features team, and a product team for the first time in my professional life. That experience marked me so much that it was one of the key factors by which, several years later, I would become a faithful promoter of agility and focus on digital product results.
We were a team of six. I would separate the development of metaSAP, and its successor ViaWise, into three significant moments where we have focused our attention on different aspects:
- Attention to delivery
- Attention to functionalities
- Attention to product results
Next, I will tell you the particularities of each moment and how I lived them.
1. Attention to delivery (tasks)
In 2003 we started the development of metaSAP. With project management so present in our heads, development was based on the proposals of the Project Management Institute (PMI) and Rational Unified Process (RUP).
The work was organized around a Work Breakdown Structure (WBS), plans, and Gantt charts, where the main concern was to complete the deliveries on time. The team received a list of deliverables and deadlines. The deliverables were in the RUP Artifacts style, such as Stakeholders Requests, Business Case, Software Requirement Specification, Deployment Plan, etc. We could call this whole group of deliverables "comprehensive documentation".
As you can imagine, between these documents and the built software, there was a significant divorce. Nothing corresponded to anything since the proposed solutions changed after being designed, and the designs were never updated. Additionally, the integration and testing of these developments were done in phases. During the construction of metaSAP, we never stopped to evaluate the results or benefits obtained by potential clients.
I say potential because it was a development of months that was done indoors following the "best practices" of the moment. The product had a technical quality and an enormous level of innovation for the standard of those years.
Already entered 2004, we had not sold it to anyone. The mistake we made was not involving any direct clients on a day-to-day basis. Instead, we did a series of interviews with potential clients that we had identified, and then we designed the solution and developed it by looking at our navel. Then, management froze the product.
2. Attention to features (output)
In mid-2005, we decided to give metaSAP another chance. The idea was to revamp their technology from ASP.NET to Java, renaming metaSAP to ViaWise, and ultimately redefining their brand identity.
Color note: one of the people with whom we worked on this project was Martín Gorricho, whom I have enormous admiration for and who years later designed the entire Kleer's brand identity and naming. Today, in 2021, Martín does not stop having international recognition for his work, and I am very proud to have had the opportunity to work and learn from him so many years ago. </ I>
Let's move on…. As we had already had good experiences with Scrum during 2004 and early 2005, we decided to use that framework for this initiative.
I joined as a developer and also assumed the role of Product Owner. Then, as PO, I would periodically meet with the company's directors (stakeholders), who would send me their prioritized requirements. Then I would discuss with the rest of the development team to give details of the feature, estimate it, and finally be developed. My main goal was not to make the mistake we made when we focused on delivery again.
So, we could say that the flow of ideas was as follows:
- Idea of feature: stakeholders
- User Story Prioritization: Product Owner
- User story refinement: Product Owner and Developers
- User story development: Developers
The goal was to meet the acceptance criteria for user stories and deliver them in time for the Sprint Review.
ViaWise started to get a bit of traction, but it still didn't quite convince the market. There were more interest and more meetings, but they didn't necessarily translate into many sales. We could say that it was a moderately valued product.
3. Attention to product results (outcomes)
By 2006 we had one more chance to get ViaWise off the ground once and for all.
The difference with the previous times is that Expofrut, a client close to the company and willing to collaborate in the development of ViaWise, would accompany us on this occasion. Here I felt the significant difference between what we were before (a delivery team or features focused on output) and what we managed to be at that moment, which I consider was a product team oriented towards outcomes.
Unlike the previous times, I no longer received a prioritized list of features (or user stories) from the stakeholders but a set of problems that the product had to solve.
The product strategy, where the company's directors did influence, determined these problems' prioritization.
Once each problem was received, the ones in charge of validating it were us, the product team, and we did it by interacting directly with the people who used ViaWise at Expofrut.
We met, interviewed them, and made prototypes on paper (I confess to having done some or other in photoshop), and we, together with the clients, we defined the features. The results that users obtained from the new features were measured in product use and operational optimization. For example, total pallet scanning time of a double trailer truck, the delay between the shift change and the first dispatched pallet, decrease in errors due to faulty scans, etc.
We did all this work without the intervention of the company's directors (stakeholders), whom we did keep informed about the evolution of the product and with whom we did measure the impact in financial terms: quantity of sales, profitability, etc.
I believe this was crucial in the opportunities that opened up for ViaWise after this work with Expofrut.
My conclusions to today
Fifteen years after this experience, and having gone through many teams as an Agile Coach or consultant in product development, I continue to remember and promote the importance of looking at the results that users/consumers obtain from those digital products built by the Agile teams.
Today I could say that I see excellent news and promising news.
The good news is that we have already overcome the delivery mindset in many companies. That mindset is oriented to projects, intermediate deliverables, and work in silos. Although many organizations still look to get out of that scheme, it is a scenario that, luckily or because of the great work done by the agile global community, many of us can already identify at a glance. This allows that when we see it, we can do something about it.
The promising is that many feature teams are beginning to see the value of shifting their attention from story delivery to product outcomes. To identify these movements from feature teams to product teams, we can list the most significant changes in specific attributes:
- The features came to them as requests from stakeholders. Instead, the stakeholders present them with prioritized problems.
- The product owner was limited to managing the backlog and, on many occasions, did not even have the autonomy to determine priorities. Now, the product owner is empowered and performs many other product management actions, such as defining the strategy and coordinating the discovery.
- The developers only influenced how to build the product but not on what to build. Now the product design capacity is in the team, and many of them are fully involved in discovery, deciding how to build and what features to experiment with solutions.
- The sprint reviews were meetings where it was evaluated if the built increment meets the specifications of the user stories, but they did not inquire about product results (outcomes). Now they are meetings where multiple factors for the success of the product are taken into account, including outcomes and, sometimes, impacts as well.
Anyway, I think there is still a long way to go to transform agile output-oriented cultures into agile product cultures. It is a step beyond much of what has been done so far. Still, the opportunity is there before, and the conscience is awakening in many community members.
I see that a new inflection point is brewing in agility. I celebrate that with great enthusiasm and eagerness; we will see where destiny finds us in another 20 years.