As a young IT professional, you might be looking into the role of the product owner to expand your career. Or maybe you are wondering what makes a great product owner and why others fail.
A quick review of the abundant SCRUM documentation will return documents like this:
Product Owners, Scrum Masters, Teams. Absent are Software Development Managers, TPMs, Product Managers, Marketing/Sales, CTOs, etc. You might be wondering why are they not there? Or you might be wondering: Why is the CTO asking for a complete estimate of time and cost upfront? Why is the TPM asking me to help define a critical path? Why do I care about a critical path? It is not in the SCRUM guide. Maybe more fundamentally, you might be asking, based on what are you supposed to prioritize the schedule? Or what do I answer when the CEO asks me how am I ensuring break even at X date. What does innovation have to do with my role? Again, it is not in the SCRUM guide.
You will not find any of these answers on any SCRUM PO guide. Some people will argue that those as responsibilities of the Product Manager, but the original SCRUM process does not consider a PM role.
Problem
The problem is that the basic SCRUM guide only works with small intracompany projects. In these situations, a PO will have access to customers as described in the SCRUM guide. Thus, you and your customer will have a simple and easy understanding of the scope and goals, again, as described in the guide. But, more importantly, you will have a wide tolerance or absence of cost tracking; you might not even need to worry about sales and profitability, much less about innovation.
If you are doing a small project inside a company for a defined internal customer, that is ok. However, if you want to deliver commercial IT solutions, that process is inadequate.
If SCRUM is so limited, why is it so popular? Why do large companies like Amazon and Netflix use it? The full answer to that is for another day. But, in short, it is because that is the best process that we have now. Companies, Academia invested years of work in rigid methodologies and Capability Maturity Models that did not work. The solution appeared suddenly in the form of the Agile Manifesto. Scrum was there when that happened and was adopted universally. The principles of Agile and Scrum work, but they are not enough. Successful SCRUM/Agile practitioners are the ones that recognize this and complement it with traditional processes and tools. SCRUM fanatics do not realize that a strict methodology is precisely what SCRUM was built to counter.
If you want to be a good PO in such circumstances, consider that you need to get proficient in the below:
Commercial Fixed Price Contract
If you work for consulting companies, this is very common. You get contracted for a defined scope at a predefined price. You might argue that this is not possible with Agile, but that is the most common contract type while working for consulting firms.
I will argue that Agile is the only way for this. The problem with these contracts is that you do not get paid if the customer’s review committee does not accept the software. So I will argue that if you just blindly follow the requirements, you are guaranteed to fail. The only way to do this is the hard way, the Agile way, the SCRUM way. Be on the look every day for the right thing to do and incorporate changes as soon as possible — the 4th agile principle: React to change vs. following the plan.
But that is not enough. Critical aspects that you will need to learn how to do / and or need to PARTNER with a PM for:
- Defining the final scope, goal of the project and agree on the success metrics upfront.
- This will change, but you need a high investment in requirements to determine feasibility, and you will need to learn how to qualify and quantify the risk of the whole thing.
- You need the most efficient schedule. You will need to learn about critical paths, Gantt charts, and finding any hidden slack between tasks.
- A good dusting in procurement processes will not hurt.
- You need to understand what quality really is, not tests and bugs per line of code, but customer value/satisfaction, the costs of not doing it, and loss functions.
- Finally, in the most Agile possible way, you will need to manage change: Detect it, quantify it, add it to the schedule, and negotiate cost/ time changes before the deadline. So you will need to keep detailed schedules and scenarios. You should not detail more than two sprints ahead; that is critical. But a successful PO will manage and review a detailed high-level schedule with emergency scenarios and tentative delivery dates every single day.
Cost Reimbursement Contract
On the other hand, we have commercial software. This is when the software itself is the product for the company, or you build it for a company that will sell it. You will need all of the above plus:
- Now it is not as simple as time saved and/or costs saved. How do you design a successful product feature bundle? Why are we doing this? Where is the product in the lifecycle: Introduction, Growth, Profits, Decline? How do you do a SWOT analysis?
- Now you need to get the project accepted, or at the very list going. Do you know how to present a break-even analysis? Can you convince the CEO that your features will achieve the marketing goals?
- What is the product roadmap as its market share grows?
- Now the customer is outside. It might be millions of people. How do you understand what they want? Can you do a survey? Do you know market segmentation? Positioning?
- Finally, all of the above is not enough. That is what the competition is doing. How do you leapfrog, how do you innovate, disrupt? As Clayton Christensen discovered, you will not find that in any of the above processes. We come full circle. You will find it thru Agile, Scrum, and your interactions with the dev team.
Conclusion
So think about the above. The PO is folded into the PM role in many companies because it is complicated to separate them. So when we look at our backlog, the PM/PO is thinking:
- Is feature A or B more aligned to the primary market?
- What is the cost? Is it worth doing C, at the expense of D and E?
- What is riskier / ROI? Do you have the numbers?
- What is the critical path? Is F outside? Can I increase scope without affecting the deadline then?
- Are we now in Scenario A or B?
- How are you going to present/defend the change to the stakeholder? All the estimates? All the scenarios? Do you have all the numbers?
Look back at the PO diagrams and org charts, look at the projects ahead, and be realistic. Get the training that you need. By all means, get SCRUM certified. But I recommend a PMP certification from the Project Management Institute and subject matter expertise to go along with that, if you pretend to determine the backlog for any medium to large project.
