In Defense of the Stack Rank

I’ve been spending some time lately mentoring junior product managers (PMs) and helping them take the next step into more senior positions.  One thing that many of them are really stuck on is the global stack rank.  While everyone seems to understand the value of a backlog these days, remarkably few of the PMs I talk to have a regular stack rank exercise.  I find this distressing.

Let me start with a couple of caveats.  One: teams are different.  There is no magic one-and-only-one-way to build software.  While I really like global stack ranks, they aren’t right for everyone.  Two: I’ve spent the bulk of my career in large enterprise software organizations.  Most of my leadership experience deals with larger teams.  My last major product had over 150 engineers and a dozen PMs.  The advice below stems from this background, so take it into account when reading.  

What exactly is a global stack rank?

A global stack rank is a high-level list of the epics you would like to cover in priority order.  It is similar to a backlog in that it sets overall priority but it is not a backlog because most of the actual work isn’t included.  A global stack rank needs to be super high-level.  Depending on how you manage your work, this may mean including only epics and not stories or tasks.  When I worked on VMware Cloud on AWS, the project was so large that we had hundreds of epics each quarter.  So, we started using Jira initiatives and stack ranked only the initiatives. Do what works for your product team. .  

I strongly prefer that the global stack rank be composed of Jira epics or initiatives because that keeps the process grounded in actual work and you can then track team backlogs to this stack rank.

Why do I need a global stack rank?

The main reason is to help engineering plan.  When you are managing a small project with less than 20 engineers, you can usually get everyone in a room and hash things out.  If you only have one scrum team, you will wind up talking about this stuff at sprint planning.  What if you have two scrum teams?  Six?  Twenty?  At some point, you can’t do that any more.

So, you need some way to clearly communicate priorities and make sure that things like cross-team dependencies are prioritized appropriately.

Let’s say you have three teams.  Team A has a deep backlog of 100 items.  Inside that backlog is tons of work that is critical for them to get done.  They also have one item that team B is waiting for and one item that team C is waiting for.  Team A does their sprint planning and starts to groom their backlog.  How high on the backlog are the items for teams B and C?  Well, they go ask B and C.  Wanna guess what B and C say?  Yeah, they both say their items are extremely critical and top of stack.  Now what?  Well, they go to PM, of course.  PM has to make a trade off call.  What happens if A, B and C all have different PMs?  Now, they pull in their boss.  Let’s say that team C has a different boss than A and B.  Now what?  Well, now they call in the Senior Director.  That’s me.  Why am I getting pulled into a debate between A, B and C?  It’s because I didn’t create a clear set of priorities for the team that allowed them to self-serve.

How do I set a clear set of priorities?

You guessed it, create a global stack rank.  

How do I create a global stack rank?

This is the very interesting part.  My guess is that if you haven’t done this already, creating a global stack rank will be difficult.  That is because you probably don’t have clear priorities across the team.  You probably don’t have clear decision criteria defined for how features get evaluated and prioritized.  Thus, decisions are made without clearly defined success criteria.  In many cases, it’s HIPPO (Highest Paid Person’s Opinion).  That’s a really poor decision making process.

What you need to do is step back and look at your larger goals.  Where does the product need to be in a quarter?  In a year?  In three years?  If you are moving fast, having three-year goals may be a stretch, but I would encourage you to set goals at least one year out.  You may be completely wrong about them, but the process of debating and setting those goals will tell you about yourself, your team and your product.  You can always change them if you aren’t happy with the result.

Now that you have an annual goal, you break that down by quarter.  This means that certain things need to be true by the end of each quarter.  A quarter is about 13 weeks; realistically that means you’re doing about six two-week sprints per quarter.  You have six chances to make something true by the end of the quarter.  If you have six things, that’s one per sprint.  Of course, things are not that neat, but you get the idea.  You want to have methodical regular progress.  You need to push things into production to test your theories so you can measure and adjust.  Thus, your stack rank needs to support those things.

Let’s say I had an annual goal of reducing customer churn by 25%.  The PM team does their research and the theory is that there are three main causes of user churn: feature gap to competitors, difficult onboarding process and lack of reporting.  Further analysis is done and it turns out that addressing the feature gap is a massive pile of work.  You break that work down further.  You now have three new features, a new onboarding workflow and a reporting feature.  Five features.  You could just put all the feature gap work at the top, but then you get no work done on reporting which is important although not very sexy.  So, you put your top feature gap at top of stack, then user onboarding, then reporting and then the other two feature gap features.  Of course, it’s more complicated than this, but I’m just giving a rough example.

It turns out that reporting is a complex cross-team initiative.  Like security or tenancy, it touches everyone.  Thus, it requires huge amounts of cross-team dependencies.  Without the global stack rank, I can guarantee that all three gap features would get done way before reporting.  Features like that tend to languish because of the cross-team complexity.  However, if reporting is stack ranked above the second and third compete features, you can then review each team’s backlog and ask, “Why is this task related to global stack rank four (your second compete feature) ahead of global stack rank three (reporting)?”

Now you are having a meaningful conversation with the scrum team about their backlog with the correct strategic and business context.

Does a global stack rank imply that features ship in that order?

No, certainly not.  Some features are low on the stack rank but very easy to do.  If I see something that my team can do in one sprint, I may just go ahead and knock it off to get it out of the way.  Similarly, if I am blocked by another team, I’m going to go deeper in the stack rank until I get unblocked.

Similarly, let’s say that of all the work in the global stack rank, the very first item that I can work on is global number 100.  Well, that’s my number 1 so I go work on that.  Perhaps I get it done quickly, before global 1 or 2.  That’s OK.  This is about helping teams make good tradeoff decisions, not about forcing them to only work on the stack rank in order.  

Three Lies and the Truth: Silicon Valley’s Biggest Lies

 

Living and working in Silicon Valley for most of my adult life has allowed me to view the industry from very close range for almost thirty years.  While in general I am thrilled to be in this business, there are definitely some strange myths that run around the valley.  You hear them repeated from time to time online and I always just shake my head.  I’m not really sure if people believe these things or they’re just saying things to drive engagement.

Here are my top three Silicon Valley lies.

Lie number three: First mover advantage

You hear all the time that getting to a market first is a massive advantage to the early entrant.  Thus, pressure is placed on teams to get in early and ship anything as long as you ship early.  This results in some really crappy code out in the wild.  

If you look at the history of software categories, it’s actually uncommon for first movers to dominate the category.  Think about things like smartphones (Apple was VERY late to this market) or web search (Google was after Yahoo and Alta Vista).  Xerox basically invented the modern computer (GUI, Mouse, Ethernet, etc.) but failed to capitalize on it.  In most cases, the first movers don’t win.

For early and emerging markets, there are so many unknowns that it’s just luck if you happen to pick the right product strategy.  I believe in moving quickly, but my focus is always to ship a quality product as quickly as you can.  Thus, my advice is always the same:  Focus on quality and velocity, not on being first to market.  Don’t ship crappy software; your users will forget who was second to market but they’ll remember your horrible bugs and crappy UX.

Lie number two: Innovation leads to success

Coming back to Apple for a moment, there is a myth that Apple has been successful in the market because they are an innovative company.  This leads to conversations about how innovative companies are as if this is actually something that you should care about.  First, Apple isn’t actually that innovative, and innovation is not their key strength as a company.  Apple’s key strengths are a good design ethic and a focus on end-to-end customer problems.  If you think about the iPod, it was iTunes that made it work.  MP3 players were a dime a dozen in those days but the iPod had a great design, looked amazing and had a full end-to-end solution via iTunes.  This made Apple successful.  They then replayed that with the iPhone and the App Store.  It’s about the end-to-end experience.

Similarly, Google derives the vast majority of their revenue from advertising.  However, Google Ads really became dominant after the DoubleClick acquisition.  They also acquired Android and several other key technologies.  Does this mean Google is somehow “less” than other companies who build all their own tech?  No, Google is a money-making machine and a Silicon Valley icon.  It really doesn’t matter if they build or buy their technology. What matters is what they do with it.  Google made good acquisitions and was able to operate at a huge scale, which made them dominant in the market.

Lie number one: Ideas are rare and valuable

People think good ideas are very rare.  They’re not.  Ideas are cheap and plentiful.  Execution and delivery is rare and hard.  

– Guillaume De Saint Marc (GSM, Cisco)

Almost everyone I talk to in Silicon Valley has a great idea for a startup.  If you hang around after work over beers, it’s common that this is the subject of conversation.  So there’s no lack of ideas.  However, turning your idea into a business is really really really hard.  It also requires an almost maniacal focus to really make things happen.

In fact, being a founder is so amazingly difficult, it is hard for founders to shift gears after their startup succeeds.  Hence the debate about “founder mode” and how long you can keep maniacally focusing on one thing instead of managing your people and running a business.  The very idea that someone who works in a medium to large scale company can suddenly take ownership and operate in “founder mode” is just bizarre to those of us working in these organizations but seems normal to founders and VC’s.

For product managers (PMs) like me,our job is primarily to sift through and evaluate ideas.  I have plenty of junior PMs who think that their job is to have great ideas.  That’s not really the case.  If you do your homework you will quickly find out that all the good ideas you need are already there. All you need to do is listen.

This is why hiring PMs based on their brilliant product ideas is not a great strategy.  You need PMs who can sift through the volume of ideas and focus on the ones that will engage and delight your customer.  Execution on a PM team is really hard and requires tedious research and effort.  The ideas are nice, but they’re not going to make or break your team.  Focus on the customer.  Solve their problems.  Move quickly to deliver high quality code.  Iterate.  If you can do those four things, you will have success as a product leader.  

The truth

The truth is that teams who ship at high velocity and quality win.

That’s it.  Move fast and produce a high quality product.  The odds are that if you can do this, you will be successful in the long term.  You don’t need amazing insights; you don’t need to have Steve Jobs levels of disruption; you don’t need to invent new computer science.  If you are moving fast, mistakes get corrected fast.  If you are shipping with high quality, your customers will stay loyal.  Operations, focus on the customer, and a high quality product—these are the things that drive success in the market.

AI is the New Outsourcing

One of the truly fascinating things about the tech industry is that despite the industry’s obsession with innovation, you continually see the same pattern happening over and over again.  I refer to this as “watching the movie.”  It’s pretty common for someone to excitedly tell me about a brand new concept in the industry only for me to realize that I’ve seen this movie before.  Sometimes, several times.  I’ll even tell people, “hey, I’ve seen this movie before.”  Because I’m an old guy, I am expected to say stuff like this.  Recently, I’ve realized that I’ve seen the “AI changes everything” movie before.  When I tell people this, they’re usually surprised or dismissive.  However, if you pay attention, you’ll see that AI is falling into very familiar patterns just like other technologies that were supposed to “change everything” but didn’t.

For example, when cloud computing came out, it was explained as this amazing innovation that had never been done before.  However, it’s basically just hosting with a better UI.  We’ve had centralized Hardware-as-a-Service (HaaS) since the mainframe and time-share days.  So, not really new, just a new way to do the same thing.

Today, we have people saying that AI will replace all your engineers—that you should allow AI to take over software development for you.  This should sound familiar.  We used to call this “outsourcing.”

The original premise of outsourcing was that you would take functions from your org that were low-value things and ship them off to a low-wage country.  The idea was to lower your labor costs by taking work that didn’t provide strategic value and sending it offshore.  What actually happened is that companies wound up building entire subsidiaries in places like India.  As a result, wages rose in India and now offshoring to India isn’t as attractive as it used to be.  Now that we’ve been doing outsourcing for quite a while, we know what the issues are:

• Communication.  It’s really hard to ensure that all the teams involved are talking efficiently and that context is shared clearly between teams.

• Quality.  Is the outsourced team doing good work?  Who is evaluating the quality of that work?

• Context.  Is the outsourced team doing the right thing?  How do you adjust their work over time?

Common advice about outsourcing goes something like this:

These points are amazingly similar to what I would tell you about using AI to build your software.  In the end, moving work outside of your core group is always difficult and needs to be managed.  For AI, specifically:

• Know what to give to AI.  AI is really good at some things like summarization but terrible at things like creative problem solving.  Pick AI tasks appropriately.

• Context is king.  When you use AI to do work for you, it’s important to have detailed context written down.  Requirements, standards, and preferences matter for AI.

• Try smaller tasks.  It’s about iteration.  Small teams, small projects and iteration are the key to success.

• Pull the AI into your existing collaboration environment.  Similar to a junior employee, you want AI to be engaged with your team.  This means that you still need things like Slack, Jira and GitHub.  Integrate your AI solution into your existing toolchain.

• Coach the AI system to drive results.  While a one-shot prompt makes a good demo, in almost all cases, you will have to sit down and critique the AI’s work and provide feedback. It’s extremely unlikely that the AI will get it right the first or even second time.

While I don’t believe that AI is up to the task of creating your application from scratch, it does provide an amazing productivity boost to your team.  For this reason, it’s important that you manage AI just like any other outsourced function or team member.  This ensures that you are getting the best out of AI just like you want to get the best out of any team member. 

So, yes.  AI is amazing and new.  However, it is also falling into familiar patterns.  As you watch this movie unfold, think about other similar movies you’ve seen and watch these patterns repeat.