My top 5 tips as Product Lead

As a product manager my role is pretty simple : make sure all the software development succeeds. Frankly, I believe that the success or failure of the team is the success or failure of the product manager.

While leading the product is not necessarily managing the team, I believe that a great product lead is in charge of all the critical element’s that leads to a team’s sucesss and I own that responsibility. Below are five key things I do to deliver success :

1. Defining Success

What does success mean? Defining the success of the product and what it means to achieve it at the beginning of the journey helps everyone in moving toward the same goal. Without defining success, it’s all too easy for the team to slip toward working on different objectives. Defining success makes it possible to create the metrics and KPIs needed to build a great product. When the team is clear on their mission, the focus to success becomes much clearer.

This needs to happen at all levels. Including :

• Defining what makes a release successful. What are the KPIs for the product post-launch? What are the QA goals? What are the must-have features? As well as what features are the should haves, the could haves and those not needed for a release.
• Defining what makes a sprint successful. Sprint goals need to be defined both in terms of story completion and non-story related ones. I start with setting high level goals and defining the features that need to be built, rather than just leading with stories as the goals. This helps the team focus on the big picture and means features are completed that add tangible value.
• Defining what makes a story “ready”. Clearly defining what ‘ready’ means having everything prepared for the developers to dive into the development. A half baked story can lead to confusion and development time needlessly spent chasing assumptions.
• Defining what makes a story “done”.  By defining what it means to have a story ‘done’, the team will have clarity on when a story is ready to ship – this will help to ensure that the product meets the criteria needed to succeed.

2. Not conceding at every turn

One of the most common mistakes a product manager could make is to continuously capitulate to outside forces. As an experienced product manager I’ve seen this happen at many levels: giving in and adding features in a platform that only one customer is asking for, adding or modifying a design to make a project sponsor happy, or lowering the bar to success because of a team shortcoming.

This will not do.

Saying “no” to a product owner or a really important client is tough, but sometimes absolutely necessary. A little concession here and there can plague a product beyond repair. There are a few great tricks I use to overcome these :

1. Conceding to testing the idea. Running a simple A/B test or user study can quickly validate or invalidate an idea. Perhaps the idea is good but it needs further work, or perhaps it’s just not a great idea. Once we have the evidence we can decide whether it’s good or not, it’s then not just an opinion but a data driven approach.
2. Creating a layer of abstraction. Using process or structure can help. The creation of a secondary layer that requests must go through can take the product manager out of the tricky business of having to say “no” directly to the client or stakeholder. This can be as simple as creating a process of voting or filtering for new requests or defining a set of criteria that must be met for new features. The solution can also be more complicated – like changing roles to have an account manager gathering customer requirements instead of a product manager.
3. Escalating team problems early. I believe concerns should be dealt with as soon as they’re identified. Meeting with team members, talking to others and taking action means paying attention to the team. Knowing what the best practices are in different parts of the business is critical, whether in design and UX, development or QA, if something is sub optimal, time to set things right is now not days or weeks down the line.

3. Eliminating Risky Assumptions

Outcomes are the measure of success. Launching a product exactly as was conceived could still be a total failure. As a product leader I’m cognizant of all the assumptions I’m making and run user tests and experiments to eliminate the riskiest of them.

Whether user testing is done remotely or in-house, the critical factor is gathering valuable feedback on the designs and better understanding the customer and the problem that we are trying to solve.

4. Stopping the Storming

It is normal for teams to have some spin. There are new libraries to try, new technologies to learn, new team members we don’t know how to talk to, and a host of other potential issues that can slow down teams. A lot of the time it is assumed the project manager or scrum master is responsible for these, but there is a lot of other things I tend to do to help make things go more smoothly:

• Including developers in product sessions. Developers love to have input. It is important for them to understand why decisions are made and take their opinions into consideration. In the end, they often have valuable insight, and their inclusion in these meetings makes them more capable to build the solution and to make all those little choices required of them on a daily basis.
• Making sure roles are clearly defined. A lot of confusion in young and dysfunctional teams arises because it’s not clear whom they should go to for different needs. Being clear on what I can provide, what everyone’s roles are and where the team can go if they need help in other areas is crucial.
• Protecting the team. The team and our objectives are the most valuable asset we have. Spending time and management capital in ensuring that they have everything they need: licenses, work-life balance (burn-out kills), time free of meetings, technical support and anything else that comes up.
• Not set unreasonable goals or deadlines. While it is important to have drive, missing dates, overwhelming developers, relying too heavily on estimations without weighing uncertainty, these all can create an environment that is not conducive to success.

5. Providing Vision and Clarity

In the end, the product lead needs to always provide the product vision. It is important to remember that most team members are heads down on their project, in the moment, and that it is up to the product manager to look constantly towards the finish line and make sure the team arrives there.

Taking the time to inspire my team with the eventual end results. Reminding them of the importance of their work. Updating them with roadmaps. Bringing them results of previous launches. Sharing the results of my research. All of these actions reminds everyone that their work is important and keeps everyone on the path to success.

In the end, as the product manager my role is to make every project a success and I do this by defining what success is, avoiding making concessions that don’t improve the product, eliminating risks, keeping the team on point and keeping a clear vision of where everyone is headed.