How to ramp up your product knowledge in 5 steps

As a Cloud Project Manager, you’re sometimes thrown into the fray and put in charge of a product deployment project where you have limited (if any) knowledge of the product in question. That is at best an uncomfortable position, at worst a dangerous one, as it limits your ability to anticipate issues. Though some consultants are adept at the ‘fake it until you make it’ method, I would instead recommend the “ramp it up until you make it” method. It doesn’t sound as good, but it’s a hell of a lot more efficient!

1. Read the available documentation

Being proactive is one of the key soft skills for a project manager. This is one instance where you should definitely apply it. If you don’t know anything about the product, take some time to read the available documentation before the project kick-off. 

The good news is that if it’s a Google project, Google offers extensive documentation about each of their product. They also provide certifications, ensuring that their Cloud Project Managers are sufficiently onboarded. The best certification to start with is the Cloud Digital Leader.

If the situation is complex (because more than one product is being deployed, or because the solution will be partly custom-built), a good place to start is the Statement of Work. Research all the deliverables listed there, as well as the description of the solution. If your Statement of Work includes a schema of the solution/product, ask your project team to walk you through it during an internal meeting.

2. Ask dumb questions to your team

I remember reading somewhere that the last all-encompassing genius was Leonardo da Vinci, whose fertile brain went easily from anatomy to physics, drawing, architecture or literature. Since the Renaissance, however, the sum of human knowledge has grown to such an extent that it is no longer possible to master several domains of expertise. 

Hyperspecialization means we can now only claim to be experts in a couple of very specific things (for an interesting overview of the relative merits and risks of hyperspecialization, I recommend this article by Thomas Malone, Robert Laubacher, and Tammy Johns in the Harvard Business Review).

In a project, your specific area of expertise is Project Management. Consequently, there is no shame in admitting to your project team that your product knowledge is close to zero and that you need simple explanations. 

Before each project meeting, ask them to explain what they’ve been doing as if you were an eleven-year-old child (or an eighty-year-old grandma). If you’re a very fun/crazy/creative Project Manager and wish to add some levity to your internal meetings, you may even go so far as to play the part of Old Granny Irma or Young Snotty Igor. Just because it’s work doesn’t mean it can’t be fun! 

3. Build your vocabulary

All professions have their cryptic lingo. This is especially true in IT, where neologisms and acronyms abound. However, simple concepts sometimes hide behind the most complicated terms. Don’t assume that it’s complicated just because you don’t understand it. A quick research will go a long way. If it is feasible, why not build a quick product glossary – in case of handover, the next Project Manager will be your friend for life.  

4. Adopt a Scrum mindset

Sometimes, what you need to know is what hides behind the technical descriptions. When following up on tasks, adding a ‘definition of done’ and a goal description for each of them will help you track their completion and general project progress (for an explanation about the Definition of Done, read this useful article on Scrum.org ).

If you gather the project tasks or actions in stories, defining these in a scrum way is also a useful trick: Adding an “as a… I want to … in order to…” description to each story will create clarity for both you and the customer.

5. Think about the broader picture

Finally, remember that as a Project Manager, your role is not to understand all the details but to focus on the broader picture, namely the delivery of the project within scope, budget and planning, with a happy customer at the end of it. In order to do that, there are only so many things you need to know at each stage of the project : 

• Are you still within budget? Will your project team need more time than budgeted to complete the next steps?
• Are you still on time? Has the work been completed according to planning? 
• Is something blocking the project team?
• If yes, how can it be removed? Who needs to be informed?
• Are there dependencies?
• What are the following action points?
• Does the customer know everything they need to know at this stage?
• …

If you keep asking targeted questions, no important points will escape your notice.

In summary, it is important to accept that there will be a learning curve and that it is unlikely (and unnecessary) that you, as a PM, reach the same level of product knowledge as a technical expert. However, by remaining curious, cultivating your interest in the topic and asking the right questions, you will be able to quickly have a firm grasp of all the topics susceptible to influencing your project’s outcome – bringing you one step closer to a successful project closure!