Can a Consultant Learn to Execute as a PM?
13 February 2017 ‧ 4 min read
In the first part of this series, I talked about the classical PM domain trifecta of business, technology, and UX. I encourage you to read that article before this one.
Key PM Skills: Communication, organization, execution
In this second and last article, I want to focus on the PM skill model of communication/organization/execution, described in this article:
I find this “skill model” described in the article much more useful to describe where consulting experience can be useful as a newly minted PM. The traditional business/technology/UX model describes domain knowledge only, and one of he key things you learn as a consultant is quickly building up domain knowledge. The more fundamental skills described in this article, however, require more training and are therefore worth looking at in detail.
1. Communication
As a former consultant, I was very well versed in formal communication (meeting preparation and execution, making slide decks, composing effective emails, etc.). The PM job adds somewhat deeper and different relationships that sometimes require different forms of communication.
The key similarity, and one that former consultants can draw a lot of leverage from, is leading without authority. As a consultant, you can never tell anyone what to do, you have to convince them by making compelling arguments. The same holds true for most PMs: None of my project teams report to me, so I will have to use the same muscle that I developed as a consultant to convince them about what I think is the right way forward.
The somewhat harder part for former consultants is the informal communication within the team, and really energizing the team and achieving full buy-in. I was a project leader at BCG before I became a PM, so I had some team-building experience there, but consulting teams are typically smaller and more well-defined than product teams — for example, in some of my product teams I might work with a marketer who is working on many other things at the same time. Also, in product teams, most people typically have stronger opinions about what is the right thing to do coming into the project, whereas in consulting teams you typically start with more of a blank slate. The best way of learning this, I have found, is experimenting and making sure to be very attentive about the level of comfort and energy within the team.
2. Organization
In the skill of organization, there is a pretty clear divide between general and PM-specific organizational skills.
Consultants excel at general organizational skills: breaking a problem into pieces, structuring and solving the pieces, and finding the overall optimal solution. This is the common way of working on consulting projects, and it is extremely useful in product management as well. Another way of looking at this is dealing with ambiguity: In consulting projects, I had to move quickly to identify what the biggest levers to solve the problem at hand are and ignore the rest. Similarly, as a PM, there are a million things I could be working on at any given time, so I can use those same ways of thinking to identify ways to prioritize what the most valuable projects are.
What I and most other consultants have limited knowledge of are the PM-specific organizational skills, which are mostly centered around the processes and artifacts that PMs use to structure their work. These differ a bit from company to company, but they will include development methodology, specs, wireframes, task management, etc. Particularly since these differ, the bar for what a former consultant needs to know going in is not as high. In my PM role at Yammer, the most important artifacts of these is the product spec — I’ve written an article just about this topic, which provides a more in-depth view how I think about this.
3. Execution
Ah, execution. This is the area in which I think consultants are most misunderstood: “You were a consultant, you only made slides, you never executed”. It’s true: the work output of consultants is words and shapes on pages. However, the same is true of designers (mostly shapes), software engineers (mostly words), and most other people involved in software development, and no one would doubt their ability to execute.
The key strength of consultants in execution is getting things done. Consulting projects are super short, and there is no time to lose. Consultants have to make sure they keep track of what is to do, follow up with others to get the input they need, and stay on top of everything while moving rapidly toward the end of the project. One key difference as a PM is that I typically have multiple projects that I need to keep track of, but frankly, the skill required in managing to-dos from multiple projects is not that different to handling to-dos from one.
The execution area in which former consultants might have a bit of catching up to do is attention to detail (and I don’t mean wordsmithing the bullets on the slide for the umpteenth time). Consultants are trained to have an 80–20 mindset. That mindset comes in handy when defining what the Minimum Viable Product should be, but in actually driving the development of that MVP, you can’t ignore all the edge and corner cases. For example, empty and error states will hopefully be experienced by way less than 20% of your user base, but they still need to be accounted for, designed, and developed. However, as I mentioned above, consultants can definitely be detail-oriented when it is required, so developing this attention to detail for the edge and corner cases only requires a bit of training.
I hope this article was helpful. If it was, feel free to follow me on Twitter where I share interesting product management articles I come across daily.
This article was originally published on the Yammer Medium blog