Introduction

As product managers it is time we take a stand. Times are changing, and not in our favor. DevOps, UX, Agile, Design Thinking, Growth Hacking, Data Science … WTF? When did we lose our hold of the reigns? We need to fight back. We need to regain our honor. We need to ship ****ing product. And to do that we need to learn how to control engineers.

Tom Cruise as Frank T.J. Mackey in MagnoliaEngineers start their careers with a spark. They want to build things that make a difference. The problem is that their caring and passion causes a lot of problems. It slows us down. It makes being a manager of product, um, challenging. Is there an alternative?

Yes!

Our goal here is to have engineers care about engineering, but not get in our way. In other words, care enough to keep working very hard, but not to ask too many questions or push back. To be successful we want engineers to relish their craft, and to take pleasure delivering exactly what we want them to deliver.

I’m going to share a secret. Engineers have a defense mechanism. They like building things and they like writing code. Engineers can exist wonderfully without really having any say in the product. Things will be rough at first. They’ll huff and puff and complain about the product team, and then go home and pick out an outfit for Comic-Con. It will pass. And your agenda will remain unscathed. Why? Because they genuinely love what they do. How novel.

Yes. This is your Product School. Here are the keys to the kingdom. I feel almost dirty sharing these time-honored secrets. Learn the skills below and you’ll smash any desire to meddle.

You will ship ****ing product.

1. Master Of Ceremony

Conduct very elaborate ceremonies! Some teams have “sprint demos”. These are a perfect vehicle to exert your power and influence. Deliberate slowly as the team demos each feature. Really play up the fact that you’re the “approver”. Use this opportunity to make it uncomfortable for engineers who fall out of line. Relish in the approver role. Toss in a bit of discouragement here and there along with some barely believable encouragement. Remember, we’re trying to incubate productive apathy here folks.

2. International Woman Of Product Mystery

Let’s face it it. You spend a lot of your day in boring meetings. But why spill the beans? Add some mystery. Disappear into available conference rooms, cell-phone in hand. You have to cultivate a persona here, which means the no one wants to hear about you checking Facebook while you wait for GoToMeeting to load. Or giving status checks to people who can’t be bothered to read a tweet-length email update. No. You are an International Woman Of Product Mystery, and meetings are where the action really happens.

3. Own Your Stakeholders

Giving the team too much access to stakeholders is simply unacceptable. How will you ever cultivate your soft skills? You, and only you, “manage” the stakeholders. When it helps your cause — for example you want to impress a stakeholder with your smart engineer friends — then it is appropriate to mingle.

Invite stakeholders to the sprint demo as well. The key here is owning the channel. Protect it at all costs. One slick tip here is to constantly reiterate to the team how little these business types know about software development. Huff a little. Complain about marketing being marketing, and sales being sales. No one will want to deal with these folks after you are done. You will OWN the channel. I promise.

4. Pressure Applied Unevenly

Pressure should not work both ways. Take test-driven development. We ask engineers to test software, and make sure things work. This is binary. It works, or it doesn’t work. That rigor is uncomfortable, and not something we want to experience. That is their world, not your world. Features don’t tank. They “miss the mark”. Priorities shift because that’s how the world works, not because we were too busy fixing our Mac after we broke everything trying to install Python. We are the fortune tellers. We are the soothsayers. Our work does not “pass” or “fail”. Make this clear, and you’ll dash interest in our side of the house.

5. Own The Problem. Choose The Solution

“We own defining the problem!” By assigning yourself the noble task of defining the problem, you’ve basically written yourself a pass. Understanding the domain is our business. It’s our special skillset. The engineers are crafters and builders. They are the solvers (or at least they think so). Lucky for us it is possible to turn our pet solutions into problem definitions. We can tire the team out until they acknowledge our genius. The irony here is that we never really truly understand the problem to solve, and our solution often informs other problems. But that’s a detail. It’s too complicated. There are problem definers, and solution builders, and we know our destiny. Control both!

6. Hackdays. Mother Of Pragmatism

Hackdays are great for hiring videos and angst deflection. When people start giving you a hard time about your pet projects, make sure to remind them about the upcoming hackday. Hackdays signal innovation. And fun. And kegerators. And a sense of unbridled impact. But common sense says … every day can’t be like hackday because that would be anarchy! People would build things quickly and deliver them to customers within 5 days or 24hrs. PMs would be out of a job. Let hackday be your carrot. Dangle it. A couple cycles of the harsh comedown — that moment when you return from hackday to your unglamorous sales-driven feature request — and your engineers will be compliant.

7. Tamper With The Evidence

Censor all feedback that will invalidate your case. Crush it like Joe McCarthy. Scan that feedback and filter out all disconfirming data. We may live in a democracy, but since when is democracy transparent? Opacity is the goal. The project is airtight. Customers have been consulted. The stars have aligned. Our intuition reigns supreme. Please follow my lead.

8. They Call This “Experimentation”

Everyone wants to experiment! They experimented in the 60s. Engineers are science minded people. They love rigor. Use this to your advantage by suggesting that people do exactly what you want them to do as an experiment. Then don’t follow up on whether the experiment was successful or not. It’s awesome! You get what you want right away, but leave people a tad bitter about experimentation. They’ll withdraw back into their craft and code, leaving endless product management possibilities.

9. Voce del Cliente

Tout up models that cast product as the “voice of the customer”. Product people love people (of course). Engineers love machines. Engineers don’t really understand people, otherwise they wouldn’t be engineers. We love people. If we didn’t we could be engineers also. But we love people too much. Please, get with the stereotypes.

You want people to be a little scared of engineers. What would we do if we didn’t have product managers here to keep them building the right stuff? Remember that one time an engineer went rogue with a feature? Exactly. We run the risk of that happening at all times. It is a constant threat.

10. Flat Is Unfriendly. I’ll Have A Tall …

We want to play up politics in our organization. A flat company is unfriendly to product managers. What would we do all day if we weren’t playing telephone between all of these holders-of-stake? Sure we want a happy environment. That’s great. More work gets done. But we want to foster a glass ceiling of sorts. Engineers … resistance is futile. Don’t stress trying to rock the boat.

11. The Project Factory, Estimates, and Velocity

We need estimates even if those estimates are always wrong. When things take longer than expected we can always blame the team. Measure velocity as well! Because velocity is the only thing coming between you and your next killer release. The beauty here is that it all distracts people from measuring YOU!

Optimize your team 24–7. Push them to the brink of overutilization. Shift them off of efforts over and over again just to eek out every little moment of slack. If you do this enough they’ll just expect that you’re going to do that … and you’ll be able to pull them off of future projects at a moment’s notice.

Status checks make people feel like they are working on a factory line. And we like that. Because we value delivery. A well timed status check can sink hearts. But they’ll come around … because they’ll start playing the game as well! Remember, keep your eyes on the prize. Shipping ****ing product.

Work with UX to get things designed way in advance. That way you can show up the morning after a big push — when everyone is eager for the data, and to start iterating — and then announce the NEXT project. There’s no time for dawdling. Those Mocks need building. Someone has to get that work done! Announce confidently that the team is at risk of missing the “market window”. “We just have to execute!”

12. Data Is Not My Mistress (I Love PPT)

De-prioritize collecting data. Data has a tricky way of shining a light on what you’re doing, and we don’t want that. What you DO want is to selectively pick out the data points that let you do exactly what you want to do. Transparency is not the goal. Take control of the tools. Own the analytics software. Hold the keys. There is a major exception … at the end of a project when somehow you cherry pick a wonderful up-and-to-the-right chart for the board deck. Ride that freighttrain to a new job in biz-dev or market validation.

13. You Say Debt. I Say …

When teams talk about technical debt, usability debt, the national debt, the debt limit, debtors, or anything else debt-related make sure to look a bit distracted. Wax poetically about needing to pay the piper. And then pass the debt on to the next generation. Or throw them a bone and do a greenfield project until they get bored of that because DevOps is busy with the “main” environment.

14. MVPs

A great way to level set expectations with a team is to ship a super crappy feature that no one is excited about (known as the MVP). Promise that you’ll iterate on it, but don’t iterate on it. This is sneaky. Because on one hand the concept of an MVP — as an experiment, and a way to deliver an early hypothesis — is appealing to engineers. So you get their hopes up! But then dash them. “MVPs that get iterated on only happen in the movies”. We do real, pragmatic work here. Namely shipping what I want to ship.

15. Hard Skills Are For Folks On The Spectrum

Don’t pick up too many hard skills. Especially around data science or other things like that. Because then you’ll actually be needed by the team, and that will take up all of your time. The team will spend less time advancing your career. You want to be skilled in the things that engineers simply cannot do (because they’re too smart). What if an engineer hears someone talking bullshit? They might actually call them on it! Or playing the political game? No engineer will put up with that crap. Their loss, your GAIN!

16. Fan The Flames Of Dysfunction

The need for product management has a linear relationship with organizational dysfunction. As dysfunction increases, so too does the need for PMs. The greater the lack of focus, the more PMs you need. The more people distracting the product, and trying to do a million things at once … YUP!, the more PMs you need. You want a sea of competing priorities because only PMs can stir this unctuous soup.

17. Our Values Rock!

Tout organizational values that are extremely powerful and engaging. It’s great for hiring. And then transgress those values repeatedly. Play up the dichotomy. You might lose some folks in the process — even some of your best people (the 5–10% who really care about the mushy stuff) — but what you’ll be left with is a bunch of people who aren’t too bothered by the sappy stuff and/or can’t afford to hit the road. That’s perfect. By exploding their bubble of optimism and altruism you’ll be able to get down to business. We need to ship ****ing product.

18. Best Foot Forward

Structure your product team such that no one really feels empowered. They’re taking orders from the top anyway. This wears the engineers out and flushes any desire for direct impact. Alas, they’re just too distint from the center of decision making. Which in turn frees you up for world domination. Hire compliant PMs as well. You don’t want anyone going rogue and empowering their team as that will set a bad example for the rest of the organization.

19. Just Because…

Nothing puts an engineer in their place better than saying something vague like “it’s complicated”, or “it is a juggling act”, or “it was a tradeoff”. Even better is the phrase “just because”. That’s a great one. It really hammers home that there is this strange alternate reality where the best ideas don’t win, political clout is valued over intelligence and skills, and there is no proof in the pudding. Never mind that engineers make cost/benefit decisions every ten minutes. That’s too concrete for this discussion.

20. Master Of Meetings

It is very important to arrive at all team meetings five minutes late, and then to appear distracted, typing on your computer, answering emails, and partially listening to the team. UNTIL it comes time for estimates at which point you jump into action and pay rapt attention. Then run off very quickly because you’ve got another meeting. This is a surefire way to make sure no one wants any part of this PM business. They’ll leave that crap to you!

Another tactic is to always be running off to meetings where you’re going to decide the future of the team. Without them being there. Works every time.

Schedule meetings during your team’s most productive time. Overwhelm the team with meetings. Eventually someone like the CTO is going to say “we can’t have so many meetings”. Leaders will go off and espouse efficient meetings. How is this a benefit?

Firstly, you will not waste as much time with your team in meetings. They’ll build faster. You can spend more meetings advancing your career, and making plans without the team. People become so sick of meetings, that they’ll associate collaboration with meetings. YES! Success. We want them to hate meetings, put on their headphones, and work on what I tell them to work on.

21. A Big Batch Of Ship-ass

Remember, from a PM’s perspective you don’t really win from the little things. You win from the BIG things. Like Texas Big. You want to have a lot of fanfare around your releases. Don’t try these little itty/bitty improvements. No … take on big batches of work. It’s less work for you (less releases to manage). When things go sideways you can always blame the team, and then take credit for whipping things back into shape.

22. Scrum. Meet The Intern

Scrum is great because Scrum will make sure you need a whole lot of junior product “owners” if you plan to scale. You have all these teams and every team NEEDS a PO. By doing this you set low expectations. It’s not like you were planning to mentor them before throwing them to the wolves. Were you? Most definitely not, otherwise you would have given them two teams. Wait. You did. Any way … Your senior developers will suddenly look over and see someone a decade younger pinning stickies to the wall. It works like a charm. Even the crustiest hackers will crumble at this point. Doggedly they’ll announce “Just show me what you want to get built, and I’ll build it!” BINGO! We’re shipping ****ing product.

23. The Mystical Backlog / Roadmap

Be very mysterious about the product backlog. People shouldn’t be able to find it, and you should always say things like “we don’t like to plan more than a couple weeks out”. We all know you can’t trust adults to look at a list of things and understand that they might change. Change that backlog and you’ll have some seriously sad adults on your hands, who likely joined the company for its reputation for incredibly boring and predictable work.

This also goes for the product roadmap. “Roadmap” is a funny word. Suddenly the product team is a bunch of cartographers? Don’t be fooled, the “roadmap” is basically an artifact of yearly planning cycles. Someone “upstairs” has asked for a sense of what is going to get built. If you’re in the real world your industry is changing monthly, not annually. With some tactical wins here you’ll leave the team apathetic about anything that looks like a giant swimlane gantt chart. Perfect. The long view encourages long-term thinking. We hate that.

Conclusion

And there you have it. Your PM training in one blog post. Repeat after me …

I can ship ****ing product

I can ship ****ing product

I can ship ****ing product

We can take our nebulous, difficult to define, context-specific profession back. One set of dashed expectations at a time.

(P.S. … hopefully the satire was apparent :)