Working with Engineers
Hard Skills for Product Managers - The Build Phase
The Snippet is a Weekly Newsletter on Product Management for aspiring product leaders.
Last week, I wrote about the hard skills Product Managers will need in the Product Discovery & finding Product Market Fit phases of transforming an idea into a real product. This is part 2 of the series. Go to Part 3 (Sales & Marketing).
As the PM moves through these first two phases, they have likely found a killer idea and have validated that it solves a problem lots of people care about.
They’ve also likely built a quick prototype to further validate/invalidate assumptions, with real-time usage and feedback from people that somewhat represent real customers. You are also quickly learning about the personas that love the product, vs. people who said they like your product idea, but in reality don’t really care .
As PM, you’ve also learned the “why” behind these behaviors. You’ve learned what’s missing in your product today and the things you need to continue to iterate upon to make sure you have a buttoned up product when you really go live. Assuming the early signs point towards Product Market fit — it’s now time to invest and transform the prototype into a real product. Welcome to the build phase.
The Build Phase
What is it that the Product Manager does in the Build Phase? They won’t build the product themselves — thats for the engineers to do. In fact, the core job of the Product Manager in this phase is to make sure build activities are not dilutive to the overall Product vision, and that you are building a Product that customers love. Despite not actually ‘building’ the product yourself, your role as a PM is to make sure the engineers and designers understand the product vision, what success looks like and — depending upon the maturity of the team — make sure that Engineers have relative autonomy in deciding how to get there.
The PM’s relationship with the engineers is a very critical and a special one. To create any product, the Product Manager will work in unison with Engineers, Product Designers etc. — albeit always keeping the user front and center. The bedrock of a strong PM- Engineering relationship is that each party adds clear value to the other and helps move work forward. A strong Product Manager will realize this quick and do exactly that.
The PM in the build phase
As we talked about, the first order of business is to make sure the builder teams have bought into your Product vision. You’ll have to ensure that the engineers become missionaries for your cause. Here’s a twitter thread I wrote on this topic some time back👇👇👇
As you discuss the gameplan with your engineers expect to get the following questions
What is it that you are asking the engineers to build?
Do you have a product roadmap? A list of must-haves, nice to haves?
Where is the user data that is driving features on your roadmap?
How will we make Product design decisions?
When do we expect to launch? What does the MVP look like?
Develop these PM Skills when Working with Engineers — and build an awesome Product
#1. Always Provide context. I was an engineer early in my career, and if there was one thing I hated the most, it was being asked to do something without any context around it. Sure I’d do it anyway, but only after I was done working on all the other requests I had some context about. You can probably see where I am going with this.
It is the PM’s core responsibility to provide context around all requests to execution teams.
One of the ways to provide context around, say, a new feature is by literally drawing out the ‘big picture’ on a whiteboard & breaking it down into executables for the team. Then traverse this ‘tree’ with the team that will build it, discuss how each small piece fits into the big product vision, and get feedback.
#2. Create a strong Product Roadmap. This is the document that you will use to communicate your vision, check progress, and align/adjust as you learn new things. Building something without a strong roadmap is akin to driving into unknown territory without a map. You will certainly get somewhere, but it won’t be where you set out for.
#3. Understand and learn how to write great user stories — here’s an example. Remember a User Story is an end goal, not a feature, expressed from the user’s perspective.
#4. Learn about the tools your engineers prefer to communicate & why — Use these tools to communicate effectively with the team.
#5. Have a 15–30 min daily standup meeting first thing in the morning with your team to discuss issues, roadblocks, and the gameplan for the day. These standups are sacred, don't miss them. Your goal is to remove any and all obstacles in the way of building the product.
#6. Be the shit umbrella for the team. If you work in a corporate setting, chances are everybody wants to have meetings with the product team for information. Say NO to these meeting requests very generously. Build time is expensive so shield your engineers from useless meetings.
#7. Let the Engineers demo what they built to the internal organization. This has many advantages. This way the rest of the organization gets the build update straight from the horse’s mouth. Engineers generally will say it like it is, and highlight challenges they see without sugar-coating them. At times that can backfire, but more often than not, letting engineers lead the internal build updates keeps everyone on the same page and gets them talking about the right things.
#8. Create opportunities for builders to interact with real customers. The PM must organize “customer days”, where Engineers can experience what a typical day in the life of their user looks like. It really helps engineers empathize with the person that will use what they build. Very very powerful.
#9. Learn the art of building small and making trade-offs. The PM should be able to distinguish bells and whistles from the most important & indispensable features quickly. Also, avoid the “Edge Case” Trap.
#10. Be Decisive. The PM is the one that makes final decisions on the product and what to build and what NOT to build. The team expects you to be comfortable with making quality decisions that are backed by good data. A Strong PM will always bring data to the discussion, and a Strong Engineering team will always respect that.
Once the Product Manager earns the respect of the builder teams — You will see an organic lift in your ability to move things faster through product development pipelines and most importantly build the right product.
Beginning of the “messy middle”
The Build Phase is the beginning of what is known as the “messy middle”. This is because, several complex technical decisions have to be made almost every day, and every single one of those decisions will impact your product down the line in some way. That is exactly why the Product Manager’s engagement with the Engineering team is so pivotal. You and your team must be ready to iterate, build small, and in most cases ship what you built to get feedback quickly.
As the Engineers build the Product, the PM is also simultaneously working with the Sales & Marketing teams to gear up for launch, employing a very different set of hard skills. We’ll talk about the Big Launch in the next post.
Take care and Thanks for reading!
The Snippet is a Weekly Newsletter on Product Management for aspiring product leaders.
Want to chat? I am on Twitter!
Looking for previous posts? you can find them here.
This post has been published on www.productschool.com communities.