MVP: how product managers can manage their product team for a new product launch
Minimum Viable Product, aka MVP: everyone talks about it, few Product Managers actually deliver it.
This is the 2nd part of a 2-part story, in which I try to summarise these best practices of launching MVP products from a managerial point of view. (For the 1st part, in which I discuss the product side of things you can click here.)
There is a lot of research and books on why start-ups and companies launching new products should adopt this approach. I’ve done a number of product launches myself and the good thing for me, is that every launch (successful or not) taught me some lessons. However, apart from the lessons that others learned, sometimes we need a checklist of best practices to follow along our way to a launch. Such a list could enable product managers to make sure that they keep focus and stay on the right track.
In the first part of this story, I focused on the product side of things related to launching new products. In this article, I will instead focus on the management side of things when launching new products.
Part 2: ‘Management’ side of things
Onboard the product team
When you’re working on a new product launch, chances are that the team you’ll be working with is also new. Especially in seed stage companies and start-ups, the team is sometimes even non-existent when you join it. I found myself in this situation a number of times, and the best thing I could do was to do all the points that I explained in the previous section (learning the business, talking to potential customers and understanding the MVP scope). However, once you have the first engineer (a developer or a designer) join your team, the whole job requirements change.
Non-technical (or business) stakeholders usually think of developers as technicians that know how to write code, and of designers as artists that make screens more beautiful. When you start having a ‘product team’, maybe your first responsibility as a product manager is to convince your stakeholders that developers are technical engineers and that designers are experience-engineers that work together to build technology products. But how can you convince your non-technical stakeholders that they must leave the most fun part of running a business, that of ideation and solutioning, to who they think are technicians and artists that have just joined their company? The answer is through product onboarding.
When developers and designers arrive, we must make sure that they know why they are going to be building this technology product. They need to understand not only what problem the business is intending to solve, but also how users or customers feel about the problem. They need to know the key bits, like where the biggest costs are hidden and where the most value is coming from. It’s important for them to know how competition has tried to solve the same problem but how they instead miss out on some other aspects. They need to know exactly what the potential users have said in interviews and how much of the market is represented by those remarks. In fact, they should be running some of the new user interviews along with you! Because one could engineer a successful product only if they have all the relevant information. That’s why product managers should invest heavily on product onboarding in the first few days of any new team member, and wake up the engineer within them. It’s only when the product team has the best information that they will be at their best to build a product.
Once they have all the information and they start building, then there will be moments of sharing, or demonstrations of the product. These will be the best moments for your non-technical stakeholders to grasp that the product team is not made up of a few ‘builders’ but that it’s built up of a team of engineers!
Lead the product team towards your MVP
Now that you have covered the onboarding side of things, all you have to do is to make sure that the product team stays laser-focused on the MVP scope and starts building the product. That might sound easy, but it is actually the most difficult thing to do out of all the things mentioned in this story. The reason is not because of how complicated your product, your technology or your design is. The reason is that human beings are complex creatures and managing them successfully is more difficult than any complicated non-human problem.
Flash news! People are emotional and that’s what makes them complex! You might think that an engineer is the most rational type of person in the world, but have you ever seen an engineer react to a user interacting with their creation? Engineers build things not for the sake of building something cool, but for helping out people to solve their problems. This is true for all engineers from Leonardo Da Vinci to Steve Jobs. Read Da Vinci’s letters to the duke of Milan and you will understand what really makes him excited. Watch on Youtube Jobs’ iPhone keynote speeches and you will see why he was doing all this.
Now, we all know that engineers (again, I intend both developers and designers) are very creative. They live to solve problems by creating solutions. This is a double-edged sword kind of trait. On the one hand it helps them come up with the best ways to address problems, but on the other, it pushes them out of their initial scope and leads to them getting lost in minute details and edge cases that don’t really matter. Our job as product managers is to keep them laser-focused on the main issues and guide them to spend their energy on addressing the most fundamental issues. Your MVP scope will help you in addressing this double-edged sword, however it won’t work alone. Telling an engineer to not be “so” creative is arguably the biggest mood-killer for them. So, how do you manage that?
The answer will always be in convincing them that their effort outside of the fundamentals (or, the MVP) would be a premature attempt at speculating on the future. The good thing is that you would always have either some data or the lack of it to prove your point. You can be the most creative engineer in the world, but if data shows you uncertainty or a major risk at success, you will not invest heavily in it. This is what separates a technician or an artist from an engineer, and that’s why it will help you in keeping the product team laser-focused on the launch.
Prepare everyone for the launch
As your product team builds the MVP and you start seeing meaningful demos of it, you must start to prepare everyone, both the product team members and the other stakeholders, for the launch.
As the launch closes in, the most important trait for a product manager becomes confidence. Confidence, of course, that is based on facts rather than hopes. By this time, the product manager knows a lot of stuff. We know the market, the business model, our product, how it has been tested with potential users, etc. This means we have more data than any other stakeholder, and it puts us in the best position to be more accurate than the rest of them. Our confidence is based on data.
Even with all the confidence and calmness of the product manager, the launch usually creates a nervous atmosphere in the team. It’s the D-day, it’s the lift-off and things can go wrong if people were not at their best during the months of preparation. You will have tested the entire flow of your product maybe a hundred times before the launch. It won’t be enough. There is no way for internal people to test all the possible scenarios that would happen in the first few days through an influx of thousands of users. Here is one important rule of thumb for all product launches: There will be bugs.
This is why our role as product managers is to prepare all stakeholders that it’s normal to have bugs. I usually go on to say more negative words and paint a more dire picture than what I actually expect. This is because satisfaction of the stakeholders is based on the gap between their expectation and the reality. Therefore try to push down (within reason’s limits) the stakeholders’ expectations, and you will have a happier go-live. With some luck, it will also make you seem like you over-achieved (while in reality you would only avoid being perceived as an underperformer under unrealistic expectations).
Founders will always be selling the dream, continuously, because it’s their job to lead the dream. You, on the other hand, as the product manager, you need to sell the product. So make sure you sell it well (with all its positives and negatives) to the rest of the world.
Hope that you enjoyed reading this article and that it will help you lead your next product better! Make sure to give me a like or a share if it was useful and please follow me for more product management content!
