I was never an equipment manager for sports teams in high school or college. I figured that if I couldn’t play on the team, I didn’t want to participate except as a fan.
I had a moment of clarity on a recent morning, thinking about my ability to lead as a product manager. For whatever reason, I had—within an hour of the day’s start—a “triple low” of frustration.
- In one project, I was told by Engineering that they wanted to go ahead and code a page that would allow for processing of a user’s status before sending them to the appropriate landing page. I went to Marketing to get their input on what the page should say. What I got was something else: what about tracking cookies? What about new users? Returning users? Um, OK. I guess I’ll march over to Engineering and get some answers.
- Shortly after this experience, I was on the phone with a customer. We didn’t have an estimate for fixing a problem they were having, but it appeared that we were very close. I bravely suggested it would be in the sooner rather than later time frame. As soon as I left the call, I learned that the engineer who was supposed to work on the fix was involved in another high-priority project; he might not be able to start the fix for two weeks! Talk about bad timing. Why was this just coming up now? We’d just finished wrangling with IT to get a test environment set up. We thought that was the only obstacle to moving forward; now this?
- Sigh. Then I went over to the Deployment Engineer working on another issue. Could I get from him a list of customers on the most recent version of MS Outlook? It seemed like a simple request. I explained that I wanted to be ready to triage the problem, and needed the information to know how we might proceed. What I got in response was a lecture on the need to get Engineering to focus on solving the problem and so on.
All in all, it wasn’t a very satisfying start to the day.
I have often (when not being concerned about dating myself) referred to the cartoon at the end of Rocky and Bullwinkle, where the last member of the parade is the guy sweeping up after the elephants go by. Sometimes as a Product Manager you feel like you’re that guy. Or, to get back to the metaphor in the title of this post, you feel like you’re the one handing out the towels, when you thought you were going to be calling the plays.
I thought about why this experience had just happened, and why it wasn’t the first time it had happened. It came down to a few reasons:
- The desire to move quickly. A fast pace is a way of life in startup companies, and in technology companies generally. Someone wants it and they want it now. One side effect of that pace is a kind of ADD, where you develop the skill/habit of making decisions and taking action in 30-second chunks. The unfortunate side effect of this kind of pace is that it’s easy to respond or act without questioning the premises behind the request to do so.
- The desire to add value. This is especially true if you’re experience TNGS—The New Guy (or Gal) Syndrome. You want to show people that you can move quickly, get results, and so on. So it’s easy to want to say “yes” rather than “why does your request make sense?”
- Letting accomplishment get in the way of leadership. It’s easy to focus on accomplishment (see TNGS above). You want to show results. But in doing so, what gets lost is leadership—and this is very likely what you were hired to provide. What’s the right thing to do here? And not just from one perspective (Engineering, Support, etc.), but taking into account the whole of the business? As I used to say at another company, one with a CEO named Ken, What Would Ken Do?
Getting Back in the Saddle
I got a cup of tea, sat in my cube and thought about the problem from a business owner’s point of view. I ignored the emails piling up, as everyone weighed in on what they thought needed to be done next. I stopped shuttling around between groups, hearing their requests or asking their opinions. I went back to the fundamental question: what do I need to know, to know what to do next?
- I went to Marketing and asked them for a requirements statement; the “ask” as we like to call it. What was the flow they wanted? What did the web pages need to say, exactly? How did they want to handle new vs. existing users? Once I had this, I went to Engineering and reviewed the requirements with them. After one or two rounds of clarification, everyone knew what to expect and we could move on.
- I reviewed the competing product priorities that were causing a delay in solving the customer’s problem. What were the projects? What money was on the table? How real was the estimated impact? How could we solve the customer’s problem without coding a solution? How could that be implemented? How could Engineering make sure I didn’t have to make this kind of trade-off again? Once I had the information I needed, I laid it out for the Support and Account teams: here’s what we’re doing, here’s how we’ll handle it, here’s what our next steps are.
The lesson in all of this is to take that step back and ask, “do I know why I would be doing this?” If you do, great; charge ahead! If you don’t, go get a cup of tea.