The APP Framework in Product Management
I started my PM career at a 45-person startup. It was a very eye-opening experience for me. I’m sure most can relate — you wear a ton of different hats in a startup that small. I was doing everything related to integration development short of actually writing and deploying the code myself. It was stressful! Then, when I moved to my current role, I found that while the scope of my involvement was much more refined and specific (less QA, more specific product requirements & documentation), there were multiple pieces of the product ownership process that started to surface as being paramount to refine and perfect. This was/is equally stressful!
I’m going to be spending time writing about three distinct things I believe each PM needs to internalize for success: Alignment, Prioritization and Preservation. I call this the APP framework. While it may seem obvious that these pieces are paramount for successful product ownership, I’m going to argue that it’s the assigned adjectives, adverbs and targets that really drive results.
A quick note about this APP framework — the most useful part of it is the paradigm shift when you assign different adverbs/adjectives/targets to it according to your team’s specific needs. Just keep that in mind. You can use adjectives like “Aggressive Prioritization”, or could you use another target adverb, like “Weekly Prioritization”, etc. For preservation, the default adjective that I assign is roadmap preservation, but you can modify that for what works best for your team. Try it out!
Alignment
Let’s start with the first piece of the framework: Alignment. First, what is alignment? “..a position of agreement or alliance.” is how the Oxford dictionary defines it. Something of note here is that alignment is NOT consensus. Consistent consensus is next to impossible. Alignment is more about clearly communicating with the purpose of ensuring a shared understanding of the project requirements, risks, projections and timelines. So, you can achieve alignment without consensus. In my experience, that’s more often the reality than not. There is a killer article on Continuous Alignment by Ross Mayfield that I’ll quote here on the alignment piece:
…Product Management used to be easier. You’d gain customer requirements, document them in a Product Requirements Document, throw the spec over the wall, accept a Technical Requirements Document that was in alignment. Then drive development down a waterfall and months later this product which was perfectly aligned with what customers and stakeholders specified would ship.
He then goes on to explain how this approach fails, and fails often without agile management. Here’s the thing — we know that alignment is as fragile as it is mentioned in the product development process. No matter the framework to which your team adheres, or the amount of times you scream alignment it will often fail to persist, especially if your alignment involves many cross-collaborative teams. As I said above, the most useful part of the framework is (in this case) the adverb you assign to each piece. The adjective that I’ve chosen for alignment is consistent, which is loaded. To further explain, it’s not just that the alignment is consistent, but the ways in which you pursue alignment across different orgs must also be consistent. We’re all familiar with the Golden Rule, right? I’d like to introduce the platinum rule, which is defined by Dave Kerpen as the following:
“Do unto others as they would want done to them”
When I was tasked with consistently achieving persisting alignment, I was perplexed at how often the issue arose. I had an Asana board that outlined our product pipeline perfectly — how come sales and business development leaders were still clamoring that they were unaware of our roadmap? I learned quickly that I needed to shift my approach to getting aligned with them based on the platinum rule. It’s not that the Asana board doesn’t work, it’s that teams are accustomed to being informed in different ways, and I found that it doesn’t disrupt me in any way to acquiesce to the way they’d like to be informed. So, it has become constant weekly email threads, Slack updates, etc., sometimes multiple times per week. The result? Consistent Alignment..! It may require a bit more work on my part, but the resulting benefits far outweigh the costs. Furthermore, others in your company will thank you for going out of your way to keep alignment in the way they need to optimize their own functions.
So what can we takeaway from this? Consistently align and use the platinum rule as your guide. The important outcome is alignment, and your ego doesn’t matter in that outcome. Get alignment from folks via mediums/meetings structured after the manner to which they’re already accustomed.
Prioritization
In my role as an integrations PM, multiple different company stakeholders and even engineering management can often get involved with prioritization. There’s simply no way around it. I’ve mostly seen PMs respond to this with lukewarm reactions to having different leaders attempting to “hijack” the roadmap. It just seems that friction with the roadmap is inevitable. The thing is that I agree — there will be friction as you plan the roadmap. That’s just the nature of being a PM. What you can control, however, is the way that you approach prioritizing your team’s roadmap.
Prioritization, for me, goes hand-in-hand with consistent alignment. The way I pursue it is aggressively. So, aggressive prioritization is the adjective that I assign to my methods (or, aggressively prioritize). In my case, I work with Sales, Business Development and Corporate Strategy quite a bit when it comes to decisions on priority. The problem that usually arises is that every team wants their project prioritized above the others, etc. You know the rest.
In order to tackle this problem, I started by defining a list of necessary meta-data to assign to each specific project to aid me in aggressively prioritizing. Typically these are metrics that we link to projects to measure their effectiveness. Here are a few examples:
- How will logo churn be affected?
- How much ARR will be attributed to this? How do we know that? Have stakeholders validated this analysis?
- Will this reduce the amount of times customers are reaching out to our support center? By how much?
This is how I start aggressively prioritizing. Once I assemble that data, I put them on full display for all stakeholders to see. This is the aggressive part. I try to leave no room for hypothesizing as to the value behind what others want prioritized. The value is quantitatively assessed, and that’s our source of truth. That’s it. This serves two purposes: It allows the leaders of the company to have the information they need to make a decision on what comes first, and it also achieves consistent alignment. When this is the approach it becomes clear when there are other perverse incentives at play. It also rids the discussion of any angst or pettiness as there is no ambiguity in how valuable each project may be. Instead of a Sales leader claiming blindly that “integration/project X will bring us the most revenue”, we don’t have to depend on that. We have the data that has been gathered to speak to that point.
Quick note — sometimes you can’t assess the value of projects wholly quantitatively. If something like the relationship with a technology partner is at risk, you may have to account for that as well as part of the prioritization data. Additionally, decisions may sometimes have to be made based on strategic alignment even though the opportunity is quantitatively “worth less”. In any case leadership will have the data to understand the risk/cost of pushing off that more valuable project for a new one, should that decision need to be made.
So what can we takeaway from this? Aggressive prioritization is aggressive in that you quantify/qualify the value of each initiative and then put that data on full display for stake holders. It’s aggressive because you can always refer back to this justification data. As they say in the NBA: “Ball don’t lie.”
Preservation
The last piece of the APP framework, preservation in my case refers to preserving the roadmap. At this point we have consistent alignment which leads to aggressive prioritization. Now we can use our learnings to preserve the roadmap! PMs everywhere know that once you achieve alignment and prioritization the fun doesn’t stop. Now comes the really fun part — preserving your roadmap as new challenges, requests and insights come in.
There are times when certain pieces of your product roadmap will have to be sacrificed for the greater good of the company, but if you’ve done your part in aggressively prioritizing and consistently aligning you will have the justification you need to make tough calls on what needs to go and what needs to be called up. In an ideal, static environment, preserving the roadmap wouldn’t be an issue at all if you’ve already achieved alignment and prioritization among key stakeholders. The value of what you decided to build (and the order) hasn’t changed, and neither should the roadmap.
Sometimes this holds true and it has saved me a ton of stress. I don’t have to sheepishly tell developers I’m trashing their development cycle because of something that a stakeholder just brought to my attention, for example. However, we know that the static environment is rarely the reality. If you find your product roadmap compromised, what do you do?
The first steps should be to rely on the first two pillars of the APP framework. When encountering pressure, refer to the data you collected to justify shaping your roadmap. Get the stakeholders in the same room, present them the data they need to make the decision, and run it back. You can also quantify the cost of context-switching by attributing value to your developers’ time, among other things. This can help stakeholders make a clear decision. Remember — ball don’t lie. You need the data! I mentioned above that the time will come where your roadmap must be mutated according to the needs of the company. At this point, there is a concept of accountability and ownership that needs to be driven home. I know from experience that the last thing to do is attempt to shift accountability for your roadmap, or simply throw your hands up in the air claiming that leadership hijacked your team vision.
To the contrary, I’ve found the best results come when you assume ownership of the necessary change, and work with your team to define what that looks like. Be truthful. Don’t be afraid to ask ownership/stakeholders what data they’re using to justify this. Bring that data to your team. Ask them for help. As you consistently work to stay aligned and aggressively prioritize trust and faith in your team will flourish. Developers will understand the plight and be engaged in solving the problem for the company instead of festering feelings of angst or disdain for leadership.
So what can we takeaway from this? When you can’t use the previous steps of the APP framework to preserve your roadmap, all is NOT lost. Get the team together and stay aligned. Be honest and truthful. OWN it. Reengage yourself to double down on making new plans that best suit the direction of the company, for that is the purpose of your role as a product owner.
Conclusion
The APP framework has saved my skin many times. As one engineering VP has stated, one of the goals of this framework is to CYA, or cover your ass. While that’s definitely a nice result, the main outcomes of the APP framework are consistent alignment, aggressive prioritization, and a preservation of your team’s roadmap. You may need to adjust certain pieces of the framework to fit your team’s needs, but you’ll find a lot of comfort and a lot less stress by leveraging its power.
