Navigating Chaos and Leading Teams as a PM
In June 2018, I was hired as the first PM Intern of SureConsent, and I quickly discovered what the task entailed. In an early-stage startup, there’s no product in place, no historical reference for your innovation, and with all different ideas flying around, each decision feels like a choice between life and death. So how do you control this chaos and help your team from feeling overwhelmed?
First, understand a PM's role
At SureConsent and Ericsson, I initially thought a PM is always ideating new features, developing them, and popping champagnes to celebrate launches - but that’s not always the reality. A product manager:
-
Helps their team
I once joked with my CEO at Peacefully that a PM should be renamed to Chief Unblocking Officer. Yes, we build products, but did Shah Jahan build the Taj Mahal with his own bare hands? No, he gathered the right input and resources, put together a design and plan, and empowered the people involved in its construction to execute their job effectively. That’s what a PM does. A PM doesn’t code, doesn’t deploy, doesn’t design, but they’re the centralized figure that brings all these components together to shape the product. And this means aligning everyone on your team and company to communicate:-
What they’re building
-
Who they’re building for
-
How they’re going to build it
-
Who they need to work with to bring it all together
And then, the responsibility falls on the PM to clear obstacles their team encounter to achieve and build the final product and provide visibility into its progress
-
-
To ship
A PM needs to spend time collecting feedback, iterating, but ultimately no product is ever ‘ready’ - at some point, it has to be ‘ready enough’. How to determine that? Align, align, align. A PM should provide visibility and transparency into the product to ensure everyone has enough understanding of the product’s current status in relation to what is expected of the customer and company, and they can then make the necessary tradeoffs to collectively determine if a product is ready to be out the door.
-
The right product
When building a new product, it's important to get it ‘right’. It means that the product you build must contain the features that address the right problems of users, and the way to ensure this is by constantly getting feedback and incorporating it into your product offering to make sure you’re providing the ‘right’ solution and not just a flashy UI that’s essentially a feature house. Validate ideas with data, and ensure the product is within the defined scope (more on scoping below).
-
To their users
Target someone, and you might end up serving everyone. Target everyone, and you will end up serving no one.
To me, this is what customer focus means and why it's important. Your product should solve problems for a specific type of persona, and this also helps with defining scope and prioritizing what features you should ship - it provides an identity to your product.
Defining Scope
In the face of uncertainty, scoping your project brings much needed direction and control to your team. It helps you focus on what’s important, what’s achievable, and how and when you can achieve the important goals. So how do you scope your project?
-
Empathize with customers:
Understanding their pain points isn’t enough. Gauge what they value in a product and define who they are
2. Understand your value proposition:
What will your product do that caters to the needs and values of the customers you plan to target? How does your value proposition compare to your competition?
This will help you determine what you need to get started with product and its vision, and you now have the basis to define:
-
Technical requirements
-
Business requirements
-
Functional requirements
3. Prioritization
Prioritize features derived from requirements that convey the maximum value to your users and your business.
Balancing the the two can be tricky, and using a lean matrix can help you guide your prioritization:
Strive for quick wins and big bets, and prioritize them according to the current needs of the business in relation to the effort and value they bring. Big bets may take time but will likely be worth the investment and may serve as a long-term solution; until then, focus on quick wins in the short-term to continue delivering results to both you and the customer.
Time sinks are those that require enormous effort with little value to the company or the product, and should be deprioritized or discarded.
4. MVP and Roadmap
An MVP isn’t a barely functioning product - it is a minimum viable product. It should be friendly enough with features that convey maximum value of the product to customers in a way that convinces them of the value proposition.
Define a timeline and roadmap of features that take top priority. Every organization has constraints, and a timeline will help manage that effectively and also give team members tangible information on targets to hit and how much time they have to accomplish them
Within this framework, you have to also factor in monetary and manpower cost, as a startup or even as a big corporation. But with this, we now have the holy trinity for starting any project (as I learned from my Chief Product Officer):
-
Scope
-
Resources
-
Schedule
Working with Engineers
For most PMs, this is a challenge, but I love working with engineers, and being a former engineer definitely helped me empathize with them. When working with engineers, it's as important to be a listener as it is to be a contributor. When it comes to reconciling engineering and business needs, I've learned how to advocate for my engineering team, listening to their needs and clearing their obstacles. As a former engineer, engineers don’t build because you tell them to. They, too, have a vested interested in the success of their product and what you’re asking them to build, so you have to convince them its the right move:
-
Explain what you’re building and why
Engineers want to know why exactly they’re going to spending hours and hours of development building a product, and they desire clarity to know what exactly they need to do to build it
-
Listen to your engineering team for solutions
As a former engineer, I am tempted to offer solutions but I remember - as a PM, my job is to empower, not dictate. Listen to their solution, and provide your input or ask questions where necessary. Moreover, Engineers often are best with coming up with edge cases - so listen to their feedback and listen well
-
Talk about complexity and define scope
I learned that giving them hard deadlines because a customer demands it is the number one way to break down your relationship with engineers. If a customer expectation is imminent:
-
ask your engineering team about the complexity of the task at hand
-
define the scope and features for the delivery
-
ask them for an estimate based off of this
Lastly, compromise. If their estimate is too far out from what you require, down prioritize if you have to, and communicate the conclusion to your teams and clients.
-
Be their chief unblocking officer
Engineers often run into roadblocks that they did not anticipate during planning. As a PM, it’s my job to clear their blockers and offer them the path of least resistance for efficient development
-
Give credit where credit is due
As I’ve mentioned throughout, a PM doesn’t build per se. Engineers do the hard work of developing the solution you envisioned, and often go under appreciated. As a PM, even if I get credited for a launch, I make sure to share the success with my engineering team
Know what you don’t know
At Ericsson, nothing gets shipped without compliance and security approval. As a PM, it often skips people’s minds how much you’re going to be working within the regulatory framework.
-
Learn about other components of the business that are crucial yet overlooked to make sure the product is viable
-
Approach them early: you don’t want to build a product only to have to change it at the last minute because its not compliant with industry or company regulations
-
Ask for help: teams like legal and compliance might not always be at your service. Do your own homework - ask them if there’s company resources you can reference on your own to have a baseline understanding of domains you may not be well versed in
Shared Vision and Deliver as One Team
These are parts of Visa’s leadership principles. Regardless of a startup environment or a big corporation, the hardest part is bringing everyone together. So how did I do it?
-
Visibility and Transparency
Everyone needs to know what we are building, who we’re building for and why, and where we currently are in relation to achieving our goals and objects. Any challenges, any hold ups, any changes? Communicate them to your team. The more visibility, the less confusion. Ultimately, visibility and transparency helps everyone become aligned with the direction of the product and company
2. Getting Buy-in
There are three ways to get buy-in for an idea that I’ve learned
-
Present evidence
New feature idea? Need to reprioritize? Make sure you explain why with data. If feedback indicates your top priority turned out to be wrong, be flexible enough to adapt. If feedback indicates new pain points and a possibility for a new feature for it, show it -
Empower
Need an engineering team to build a new feature and deprioritize what they’re building? Don’t come to them with a solution and demands. Explain the situation and provide context to empower them to come up with solutions. If you need their time, help them free up resources, don’t just expect them to do it for you -
Convince others
If you’re convincing the CEO or VP, my idea isn’t enough on its own. I learned its important to get buy in from other stakeholders before you even present, and bring them in to support you in your meeting. A combined effort is more convincing than a lone wolf venture
In summary, a PM isn't just shipping products out a revolving door. Being a PM is about understanding and prioritizing your customer and business, providing alignment and direction, and enabling teams to do their job to the best of their ability.