Burritos are great. The combination of ingredients, flavors and packaging is pretty much unbeatable. I’ve eaten them at restaurants and at home and although I can make pretty decent fillings, I’m just not as good at folding them as the maestros you find at most Mexican restaurants. Inevitably, stuff falls out onto the dish.
They are tricky to fold properly because you need to be careful choosing the ingredients you want in, how much of them to use, and fold the tortilla with the right technique. In my case, I fail because amidst my eagerness and hunger put too much stuff in. Also, I lack the motor skills to follow the folding steps properly.
In any case, burrito folding’s essence is a mix of constraints and execution concerns.
On the execution side we have the process of making the burrito happen: selecting the ingredient combinations and tortilla size from what’s available, putting the fillings in, following the folding technique and even choosing a drink to go with it.
On the constraints side is anything that defines the possible execution: the grocery budget, the ingredients we buy, tortilla sizes, the folding quality we want to achieve (AKA “stuff-falling-out tolerance”), and if we were to be selling them, the individual pricing.
Out of all these factors, the best possible burrito should come out. Individual criteria will differ but in the end, we will all have some form of burrito that fulfills said criteria.
Bringing it back to software
Of course this is also the game we play everyday as software Product Managers. The role goes by many different names and descriptions, but in simple terms it’s the person that sits at the middle of the software process making sure that the best possible burrito software product comes out in the end. We are Burrito-Folders.
The words Best and Possible are key. Each relates to a different side of the equation.
Best encapsulates the execution side, assuming everyone wants to produce work of the highest quality they can. Possible is what reigns us in; we don’t have infinite resources and are faced with constraints that will force us to make choices. Achieving the right balance is the Product Manager’s job.
In our world, execution comes from the "make it happen"™ teams: engineering, design, marketing, operations, data, etc. Over the past few years there’s been a big convergence towards cross-functional product teams using some sort of Agile development methodology, and although there’s never a single approach that works for everybody, at least there’s some structure.
It’s on the constraints side that entropy rules, as it’s the most human-heavy. I’m talking about product strategy, budgets, requirements, team composition decisions, business deadlines, roadmap prioritization and planning. If on top of that you’re working as a consultant, you also have to handle more communication channels and dealing with stakeholders that may not be as product oriented as you and your team.
Decisions and actions within all of these areas can be based on hard quantitative arguments as much as subjective and hard to understand reasons.
Communicating with the technical execution team is a big part of the PM’s job, but it ends up being the “easiest” one. Being able to navigate “constraint-land” is what makes you effective: our most important job is to ensure the widest Possible for the team to do their Best.
The Execution side of product building is obviously important and fascinating, and still is, as in all of software, an unsolved problem. But since there are already many great resources on those topics, Folding Burritos will focus on the Constraint side. The “hard” part of making software happen.