The Pirate Code - A set of rules for better decisions

Pirates are a tricky bunch and if there's one piece of advice I can give you, it's not to trust 'em! And I'm not referring to a computer whiz getting you bootleg copies of The High School Musical, I'm talking about good old, swashbuckling, patch wearing, peg-leg walking, parrot talking, shiver me timbers pirates.

Recognizing that their line of work, driven by greed and conquest, was an open invitation for chaos, pirates implemented rules, known as the Pirate Code, to keep emotions at bay and the ship in relative order. Unfortunately for the crew, most of these rules that included punishments ending with "as the Captain shall think fit" so it wasn't quite as democratic as the world we know today, but nonetheless, there was at least a semblance of order. 

While Blackbeard may be gone except for history books, those same emotions that risked the collapse of all of pirate culture still exist in us today and occasionally, we need to be protected from them. (Side note: For a fascinating exploration of how our capacity for emotions allowed to us to dominate the planet, check out this book).

As product managers making decisions on a daily basis, just because you were up all night taking care of your dog who is scared of thunderstorms, your kid got mud all over the inside of your car on the drive to school, you spilled your coffee on the way into work and consequently are in a bad mood doesn't mean you should prioritize things any differently today than any other day. But chances are, you will because we’re human, emotions are high and they crowd out those logical thoughts that we need for sound judgement. If this doesn’t affect you, you may be a robot.

Not helping our case, Recency bias (giving greater importance to more recent events or ideas) will also cloud that judgement, encouraging us to focus on features that have been top of mind recently than a more important feature that hasn't been talked about much in the last few weeks. Add to that a few dozen other biases that may be impacting our judgement at the same time and the odds are certainly stacked against us. By improving our self-awareness around these topics, we can at least make incrementally better decisions with the ultimate goal of reaching better outcomes for our teams and our products. To do that, we need our own Pirate Code to keep emotions at bay and our ship in relative order. 

The Product Manager's pirate code

The Product manager’s pirate code should be a set of rules to help us make better decisions, which is a concept that has been discussed at length using another, far more banal term, prioritization frameworks. Most people agree these are useful in principle, however in practice we find that most teams don't consistently use them for a couple reasons we'll explore later. 

My preferred prioritization framework (or Pirate code, which sounds much cooler) is the RICE method because it is easy to use, doesn't involve any complicated mathematical modeling formulas (which I contend are of dubious value) and balances both the costs as well as the benefits of building a particular feature. 

For a quick primer, RICE is an acronym standing for:

• Reach

  • How many users / customers will a feature impact in a given timeframe? You can use any value here but you get bonus points if this value comes from actual product metrics rather than a number you grabbed out of thin air!

• Impact

  • Of those people a feature will reach, what impact will it have on them? You can use any scale here as well. I like to use 1, 3 and 5 where 1 = minimal impact (they might not even notice), 3 = moderate impact (they'll notice but likely won't change any behavior) and 5 = major impact (they will adapt their behavior when they use the feature).

• Confidence

  • My favorite part of the RICE framework which factors in how confident we are about our knowledge of a feature. This is a combination of confidence in each of the other three values: Reach, Impact and Effort (complexity). I like to use a score out of 100 where 50 of those points are confidence from the PM team in the reach and impact. The other 50 points are confidence from the development team in the effort. Add those two together and you get a percentage.

• Effort

  • How much time will this take? Again you can use any value here, but person-weeks (how many weeks it would take a single person) or t-shirt sizes are common values which will depend on the time scale of the features you are prioritizing. 

And now for some simple math:

Example:

10 customers x 5 (major impact) x 0.8 (80% confidence) / 5 person-weeks effort = RICE score of 8

Then it's just a matter of picking the ones with the highest score right? Oh if only life was that easy🙂

When prioritization frameworks break down

What happens when your RICE scores don't match up with the "gut feel" priority you had in your head? There's yet another psychological force at play here, Cognitive dissonance (where our actions don’t match up with our beliefs), which is telling our brains that this ranking system can't POSSIBLY be right because it doesn't match with how we’ve already ranked these features in our heads. 

This is the largest reason teams don’t consistently use any given framework and they abandon their Pirate code. It doesn’t give them the answer they want and admitting that their gut feel prioritization may be incorrect is an insurmountable mental barrier.

For those who try to stick it out and follow the code to the letter of the law, I've seen people usually do one of two things at this point:

• Go back and change the numbers so things fall in the order you wanted them to initially

• Adding a "factor" multiplier which allows you to multiply the scores by some factor you determine for each item so they fall in the order you wanted them to initially

Either of these activities will destroy the utility of your prioritization framework. Avoid them at all costs! 

As hard as we try to objectively prioritize work for our teams and products, the world of enterprise product management does not behave according to a strict set of mathematical rules like it may for astrophysicists. There are always exceptions and there will certainly be times when strictly adhering to the numbers is a bad decision. So what then?

Where pirates got it right

For some inspiration, we can look to everybody's favorite pirate ship featured in Pirates of the Caribbean, the Black Pearl. Captain Barbossa of the Black Pearl hints that "the [pirate] code is more what you’d call guidelines than actual rules” and while the historical accuracy of this statement is perhaps a bit suspect, given that the entire story is made up, the principle can still apply!

Product managers use prioritization frameworks as an attempt to help steer us in the right direction, stay on course and mitigate the effects of all the forces (psychological and external) that are trying to sway us one way or the other. But these frameworks should be used as guidelines, not strict rules that must be followed to the letter. They are intended to help us make better decisions, knowing that we will never make perfect ones, and even an incremental improvement is of value. 

Whatever framework you choose to experiment with (and you can always try out a few to see what sticks), give yourself permission to deviate from the prioritization order it prescribes.

If you have a good reason to deviate, then deviate away! Document your decision so you can reflect on it later (mitigating some other memory-based biases here) and once you’ve gone through your prioritized list, it’s a good idea to take a step back and review. If we believe that this framework will help guide where we should be spending our time, then most of our efforts should be spent on items near the top of the list. If you find yourself deviating quite frequently or in a majority of cases, that’s a signal to zoom out and re-evaluate if something else is influencing your decisions.

When we just prioritize based on gut-feel, we miss out on this opportunity to reflect on what may be influencing how we make decisions. A framework is an excellent tool to give yourself some guidelines to aim for and should you deviate, ensure that you are doing so intentionally rather than unconsciously. Without a code of our own to keep us on track, we could end up unknowingly sailing off into the mist, right where the pirates are waiting for their next plunder!

And He Sticks the Landing

Landing and reusing a rocket has become a seemingly everyday activity that no longer inspires the sense of awe that it used to, despite the absurd amount of technological coordination involved. Call me an old man pining for the days of yesteryear, but launching a flying bomb into space, deploying a payload, and then landing that rocket back on Earth, only to launch it again a month later will always get me excited. 🚀

And while reusable rockets are an incredible accomplishment of human brainpower thanks to literal rocket scientists, often overlooked are the number of safeguards that had to be designed and implemented in case things don’t go according to plan. You no longer have a rocket on a one way ticket up and out over the ocean, safely away from humanity if it explodes (sorry fish). Now these rockets are coming back to land either on the coast or on drone ships, near civilization and expensive infrastructure. And thanks to the transparency of SpaceX, we have plenty of blooper reels to show how things can go spectacularly wrong. 

Space and Software, about equally as hard

Just like space, in enterprise software, if something goes wrong in our application, it isn't as easy as quickly deploying a fix that is immediately pushed to every user (alright maybe space is a LITTLE more complicated but close enough 😉). Enterprise-scale companies usually always desire tighter control over their applications and upgrades are not as simple as they are in many B2C applications. Consequently, we need to exercise even more caution when designing our products and considering what happens when things break down. Bugs are going to happen, so let's be realistic and make sure they degrade gracefully and don't result in a catastrophic fireball!

SpaceX takes extra precautions in the safeguards they employ as part of their hardware engineering process to ensure any threats to human life (and expensive infrastructure) are limited, utilizing a Guilty until proven innocent model which assumes something will fail unless proven otherwise. Pessimism is rarely rewarded but in this case, often can save the day; while people people deserve the benefit of the doubt, software deserves the presumption of guilt.

A great example of this principle in effect can be seen in the landing sequence for the Falcon 9, SpaceX’s workhorse reusable rocket platform, as depicted by my scientifically accurate representation below.

Very scientific depiction of actual rocket science

After the rocket has launched, deployed its payload in space and is returning to Earth, the guidance computer assumes that something will go wrong during the landing sequence and intentionally aims the rocket to miss its intended landing point, either a landing pad on the coast or a drone ship in the ocean. It continues on this "miss trajectory" until the very last minute where, if and only if everything checks out, the rocket corrects its trajectory to land in the intended area. By following this seemingly procedure, SpaceX minimizes the risk to personnel and infrastructure posed by a failure early on in the landing sequence. Even if something as severe as a total engine failure occurs, the rocket is aimed for a (relatively) harmless splashdown in the ocean until the last minute.

Incorporating fail-safes into software development

This sequencing demonstrates a fail-safe in the most literal sense by assuming the system will fail and designing around that condition. Fail-safe designs are around us every day in the world and used extensively in systems engineering but we don’t regularly apply these same principles to software development. After all, a software product is just another system with many pieces depending on each other. In an enterprise world where the cost to fix a failure is often both high and painful, fail-safes can save the day if software is assumed Guilty until proven innocent. 

The more common approach currently taken in software development is exception based. We assume the system will follow the happy path and we try to catch all the exceptions that could occur, individually and explicitly. Why doesn't this work well? It relies on our own ingenuity to determine ways in which the system could break. There’s no reason to put that burden on us when we can instead assume the system will break and design for graceful degradation. 

To explore an example of this principle applied in the real world, a team I worked with built a feature to audit user activity in a software product. Knowing exactly what a user did in the system was critical to comply with federal regulations so our audit records had to be pristine and completely accurate. Perhaps not the most glamorous of features for you UX folks but it certainly posed a fun technical challenge!  

Since our audit records were stored separately from the main application database, using the traditional exception-based approach, we had two options of how we could build the feature:

Option #1:

• User takes action

• Update the application database

• Record the update in the activity audit database

What happens if recording the update in our activity audit database fails? Now we have an update that occurred in the system that we didn’t audit. 👎

Option #2:

• User takes action

• Record the update in the activity audit database

• Update the application database

What happens if recording the update in the application database fails? Now we have an audit record of something that never actually happened. 👎

By applying the guilty until proven innocent principle, we ended up with a solution incorporates fail-safes and gives us an opportunity to identify anomalies by reconciling the matching attempted and succeeded records.

More importantly, we didn’t have to sit in a conference room for half a day trying to imagine where the feature could break down, we just assumed every step would fail and decided how to handle things when they did. Here’s where we landed:

• User takes an action in the application 

• Record that a user attempted an action in the activity audit database

  • When this fails, full stop since we haven’t made any changes yet

• Update the application database with whatever the user changed

  • When this fails, record that the action failed in the activity audit database

    • When this fails, we will catch this by reconciling orphaned “attempted” records

• Record that a user successfully took an action in the activity audit database, paired with the attempted record

  • When this fails, we will catch this by reconciling orphaned “attempted” records

Alternative applications

One drawback of this approach (after all, nobody’s perfect!) is that we can end up with a more complex implementation with these failsafes built into it. That’s not always a bad thing depending on the importance of the feature or product we are building, but like most things in life, the rule of when to apply this idea is “it depends.” 

We also don’t have to implement every failsafe either. Sometimes, just using this approach as a thought experiment is good enough and the team can consciously decide that there are a few failure cases that aren’t worth worrying about. But without thinking this way, you may never know that those failures could occur (until your highest paying customer finds them for you) and I would rather decide explicitly to ignore them than decide by ignorance.

You can also use this approach to pressure test designs with the UX team. In my experience, initial designs of a feature usually address the happy path and as a Product manager, you are then responsible for vetting the design with the technical team to tease out the details and edge cases. If you assume that design is guilty until proven innocent, you can proactively address these issues before development even starts, hopefully reducing bugs and found work later on down the road. 

This may feel a little technical but at the end of the day, as a Product manager, we are responsible for making sure our product doesn’t completely implode when a customer tries to use it. A great way to help avoid that is instilling this principle with your teams using a simple shift in language that starts with you, maybe with a few examples of rockets blowing up to really land the idea. 😉

Instead of specifying in our Acceptance criteria "if any of these things are not present, then show this error", which assumes the happy path, we can instead frame the requirements "if all of these things are present, then proceed to the next step.” This means we don’t need to specify every single possible permutation of what could go wrong, all you have to do is identify the criteria under which it will succeed and help development teams learn to make those same assumptions. 

So what's the difference if you use just slightly different words? Changing the way our product teams approach problems. Instead of assuming our products will succeed, we should instead assume they will come crashing to the Earth at over 300 MPH, ending in a fiery inferno and millions of dollars in damage. And then when our products do succeed, they land gracefully and the world is none the wiser that they were aimed to miss the landing pad until the very last minute. 🚀

All-You-Can-Eat Buffets and Lunch Trays

The All-You-Can-Eat Buffet. Possibly America's greatest invention, closely followed by two equally important ideas: the Weed Whacker and the Internet. Where else can you indulge every savory and sweet taste bud you have over the course of 6,000 calories for the low low price of $9.99? 

We have all been there, whether we like to admit it or not. We walk in thinking we'll get a little of this, a little of that, some veggies from the big salad bar they have, maybe a slice of pizza if we're feeling particularly indulgent. Only to realize upon sitting down at our table that our plate is a cornucopia of: pasta covered in Alfredo sauce, garlic mashed potatoes with gravy, a slice of yellow cake and a slice of cheesecake. We had the best of intentions and instead went for carbs covered in either some form of cream sauce or sugar.

And damn was it good. 

The greens are cooked in bacon fat, don’t worry they aren’t healthy!

Now please contrast that with everyone’s second favorite culinary experience, school lunch. A faded plastic tray with 6 compartments, each filled with a relatively unidentifiable source of calories, usually served with a spoon and a small space for silverware at the bottom (Sporks, another one of America's finest contributions to the world, patented in 1874). 

Despite useful trivia and such a glowing review of those delicacies we enjoyed between art class and recess, I would like to propose that School lunches are better than All-you-can-eat buffets. Let me explain.

Humans aren't the best at self control. We have great intentions, all of which are swept under the table, along with the crumbs of our third piece of cornbread and disregarded as soon as we see that swirling display of cake slices with their caramel coatings glistening in a halogen colored spotlight. And when it comes down to it, we often simply pick the easiest choice or whatever satisfies our craving the most. 

As a product manager, we want more than anything to get new features in the hands of our users. That’s our craving, our cheesecake. So who in their right mind, when given an empty plate, is going to fill it up with a salad that will take 10 minutes to make, another 3 minutes to appropriately toss with dressing and then 20 minutes to chew through, when instead you can fill that plate up in 30 seconds with carbs that are half-processed for you already?! 

And here is where school lunch takes the cake. hehe

With school lunches, you don't have an empty plate. You have a tray with meticulously, precisely and scientifically portioned compartments, each with their own purpose. One for the main entree, one for veggies, one for fruit, one for dessert, one for milk and one for silverware. It would look pretty out of place if you filled all of those up with cake, so instead, you follow the guidelines and fill it up appropriately, maybe sneaking in an extra fruit cup here and there. 

Decisions, decisions…

Lunch trays provide a framework for us and offer protection from our own human tendencies. They take some of the freedom out of decision-making that can get us in trouble (like only eating cake) but they still allow some degree of independence (do you want carrots or broccoli for your vegetable today?). And no humans are exempt from these temptations. The easy things, the most rewarding things, the things with the lowest barrier to entry, all are tempting and often, these are all too easy to pick over the hard things, the truly valuable things. 

Product managers own prioritizing which features to build and ship from a veritable buffet of options, especially in enterprise where the feature requests are numerous and nuanced. It just too easy to pick the quick wins, the features we’re most familiar with, or the ones for the customer screaming the loudest, something I’ve done more times than I probably like to admit. But we can’t, and shouldn’t, be trusted to pick an appropriate balance from that buffet without any guidance (we’re humans too!) and we need a lunch tray to help us make the right choices. 

Everyone’s lunch tray will look a little different. Prioritization frameworks come in many shapes and sizes, from quantitative ones like Opportunity Scoring to qualitative ones like Pruning the Product tree (a favorite of mine) and it will depend on both your product and your organization, probably with some experimentation, to determine the one(s) that are the best fit for you. But whatever you do, don't go in with an empty plate! 

So when you are picking features out of your backlog for your next release, you can ask yourself, am I using a lunch tray to make the right choices? Or do I have an Old Country Buffet plate full of Mac 'n cheese, Freedom fries and ice cream?

In Favor of the Fixer-Upper

When my wife and I bought our first house (there’s an industry ripe for disruption to the user experience!), glaring inefficiencies aside, it was an eye-opening exercise in prioritization. Turns out finding the perfect house is a tall order, but finding a home that fits most of your criteria isn’t too hard. It all came down to establishing what the bare minimum features were that we wanted in a house. We decided up front that having 3 bedrooms and at least a 1 car garage were unshakeable requirements. Once we’d established this criteria, or our house MVP, we didn’t even consider houses that didn’t have at least these features, among others. Even when a beautifully done, perfectly laid out 2 bedroom house in one of our favorite areas of town hit the market, we didn’t look at it because it didn’t meet our criteria. The first time this happened, it hurt. We felt like we were missing out on a great house. But after a few times, we got used to saying no when it didn’t meet our needs and it became a game! It was almost more fun to reject houses than to actually go look at them. 

    Was this being this strict really necessary? Probably not. After all, with enough time and money, anything is possible. We could have bought that house and considered constructing a third bedroom through an addition. But we didn’t. Instead, we found a wonderful 3 bedroom house with a little less charm, but still met all of our baseline criteria. It had three bedrooms, a two car garage, a private back yard and plenty of potential. A few cosmetic updates, a few changes to the landscaping out front and she would be perfect! Our thinking at the time was: 1) holy crap we’ve never spent this much money in our lives and 2) at least it has the bones we want, we can always remodel over time. We found the MVP house and we went for it, warts and all. 

    Prioritization as a Product manager is constantly a balancing act between a "good enough" MVP and a “fully finished” product. Where on this spectrum you guide your product team can determine how successful your next release is and house shopping helped me find where to fall on this line.

When most people shop for houses, they make sure a house has the basic amenities they want before weighing the aesthetics. Nobody said “I know we said we wanted 3 bedrooms and this house only has 1 but it’s reeeeeeally pretty.” If your business is evaluating new software tools for HR, are they more likely to reject a vendor because the software is missing functional feature requirements or because they don’t like the way it looks? 

Release prioritization

       Releases in the enterprise world aren’t usually as fluid in scope as they are in a B2C or SMB environment. Large companies want to know what is coming up so they can prepare their infrastructure, plan trainings for their teams and make sure their feature requests are being built. Consequently, you don’t have as much flexibility in what features must be in a release.

So with scope pretty well defined, as you work towards your next release, there’s two approaches you can take to how you prioritize work for your teams as a Product manager. 

Option 1: Close it and move on

• Build a feature to completeness with a clean UI, all the edge cases covered.

  • Close out all of the work for a feature before starting on the next one.

Option 2: Take a first pass at every feature

• Build a basic attempt at each feature and move on to the next one before you put polish on anything

  1. Don't close out work on any feature until every feature you want to release has a first pass built.

    As humans, each with our own little bit of OCD, Option 1 feels better to us because we get a sense of closure and we can move on to the next feature. But this can be a costly mistake. If your product isn't useful until 10 specific features are supported and you only complete 8 because you spent too much time fiddling with minutia, you've let down your customers and haven't met the most basic requirements of your users. 

    Instead, Option 2, what I call the First pass approach, ensures you have at least the bare minimum for every feature before you go back and make anything fully polished. In other words, opt for the 3 bedroom house that needs some remodeling work instead of the finished 2 bed because at least everyone has a place to sleep. Then, with whatever time is left before release day, you can iterate and improve on what you already have in place; remodeling a bedroom is always cheaper than building one from scratch. 

    The First pass approach helps build protection into your process to ensure form follows function and that your teams are spending time where it is most important: making sure you don’t have a half-functional product when it comes time to release. 

    Now this certainly won’t be a popular approach with, well pretty much all of your stakeholders, but people hire Product managers to make the tough prioritization decisions so saddle up! 

• Design teams won’t like it because instead of building the charming suburban bungalow they designed, you’ve built a cinderblock box with a single window. 

• Executives won’t like it because you’ve fudged the definition of done and you can’t tell them when it will be “move in ready” for customers. 

• Sales teams won’t like it because you can’t give them screenshots of what the interior will look like since that depends on how much time you have to remodel.

Take it to the Next level

    The First pass approach isn’t a new idea, but teams often don’t take it far enough and still get stuck in the trap of “just putting a few tweaks on it now to clean it up.” This is where you pull the fire alarm and evacuate the building. It goes against our nature to leave something half-finished and that is the most critical part of this idea. You must move on from a feature once it is minimally functional and start on the next one. This is a tough pill to swallow and feels like mixing up a batch of cookies but never putting them in the oven. And every day you come into the kitchen, and see sheets and sheets of cookie trays sitting around you, almost done but not quite there. The good news is people still buy cookie dough, sure you can sell fresh, warm and gooey cookies for more, but at least you have something to sell, even if it isn’t fully-baked.

    Many people I've talked to resist this approach because it feels so unnatural and they are concerned about the realities of remembering to go back and tidy up this trail of almost-completed features streaming behind you. Logging items wherever your work is tracked can help mitigate these concerns or something as simple as a note called “Release cleanup” will do in a pinch. Either way, writing it down puts your mind at ease and frees up other space in your brain for more pressing matters, like encouraging your team to move on to the next feature.

It comes with other perks too

    An interesting side effect from this strategy is an improvement in team morale as they build momentum and begin to see a working feature set or application come together. Without burning a lot of time on styling and perfecting, the pieces of the puzzle will come together faster. We have all been trapped in the slog of the nitty gritty details with features that seem to drag on forever and you can feel the momentum being sucked out of the team. The First pass approach keeps the team moving on to new things and that novelty is exciting for our brains. Even when you return to add a little polish to a feature you built a couple weeks go, it still feels new to the team because they've been working on other features in the meantime. While often overlooked, these mental victories can help build your teams’ sense of pride in what they are building and also strengthen their investment in the product which will come in handy when it’s down to the wire for release day. 

    At the end of the day, it is on the product managers to make sure that our product meets at least the basic needs of our users come release day. Maybe it won’t have stainless steel appliances and it might still have Grandma’s pink floral wallpaper in the bedroom, but at least everyone has a place to sleep. You can always remodel, iterate and improve. Take a first pass and move on.

Happy house hunting!