Part Two: Key Elements to Become a Healthy Product-Led Organization
The path to successful product-led growth is a tough one. What you want is for stakeholders to build good habits around roadmap completion, but unfortunately, this doesn’t always happen.
In our previous article in this two-part series, we looked at the importance of having the leadership team establish a high-level strategic baseline, communicating their tough choices to allow everyone to understand their roles within the product management team — and how these are the key ingredients that create the conditions for successful product-led growth.
It’s also recommended that companies turn their reassessment of high-level strategic baseline choices into a habit. The mantra is that you should scale back strategic ranges and simplify strategies to your own benefit. Because it's normal to get all kinds of new requests — and these usually come in the form of feature wishlists from the CEO, customer success, sales, marketing and engineering. These feature requests across departments always correspond to problems needing to be solved. Here’s a look into where each department is coming from when making requests:
- CEO: The CEO will evolve the company's visions, the product’s high-level strategic baseline and communicate it in a clear and explicit way. They might suddenly fall in love with shiny objects, new technologies (like AI or blockchain) or the R&D team might have come up with something they wish to commercialize with no valid market. In doing so, CEOs dilute the product mission, strategies and tactics beyond recognition, causing product teams to lose control.
- Customer Success: Customer Success, responsible for the onboarding of new customers and supporting them throughout their journey, have a lot of bugs to fix, optimizations to recommend, as well as issues and blockers that existing users are experiencing. They're very empathetic towards the user but there's a cost to fixing every bug the product has, which is why product managers are put in the middle to evaluate priority versus severity, oftentimes highlighting the interruption cost of fixing a bug
- Sales: Sales will always have requests that come from prospects — oftentimes backed with self-conviction and no real validation. They are competing to close that ‘million-dollar MassiveCo client’ who's not going to sign unless you were to deliver that special feature. As such their problems revolve around the product not containing the right features which will allow them to qualify prospects.
- Marketing: Marketing will look at competitors and ask for similar features or will have problems with the branding, always wanting to make design changes to the user interface so the look and feel of the product are more on brand. The marketing team problems revolve around the product not being the number one lead magnet it should be (e.g. not as slick as the competition, missing features, etc.)
- Engineering: Engineers will usually wish to make the code more maintainable, easier to understand or more scalable. They have their own pet projects as they see opportunities to improve the product or further sharpen their skill sets by leveraging new technology. Engineering team problems revolve around quick time-to-value — as in decorative but non-essential features customers enjoy but have no business value.
As a product manager, you're at the intersection of all these departments. The process to follow is one where you ask all stakeholders to submit any feature request to you and only you (not engineering, not QA, not the CEO). Your job is to filter these requests through the decision-making framework, move evidence up the confidence meter from "I’m convinced this is the right thing to do" to anecdotal evidence, user studies and data support, making sure that they have enough beef to justify an investment in engineering resources.
A new feature always comes down to a problem needing to be solved. It’s really up to them to come to you ready to define what the problem is and use the decision-making framework to validate their spot in your feature backlog.
Product Lifecycle Management and Feature Parking Lots
Product lifecycle management is the process where all the ideas, feature requests (good or bad), bug fixes as well as any innovation or evolution of the product is kept. Included in this process is the concept of creating a feature parking lot. Fundamentally, these are features with a parking brake.
Every input, idea and feature request you get from the outside world (customers, executives, sales or marketing teams, etc.) should end up in some sort of a container. We recommend keeping a list called "The parking lot". This is where you keep every suggestion, wishlist item and feature request. It’s not considered to be part of the roadmap.
As a product manager, you’re responsible for grooming the parking lot tickets on a regular basis, making sure that items are relevant, discarding the ones that perhaps are no longer valid. Everything that winds up in a parking lot won’t become a feature. You’ll need to analyze each feature request to see if the time has come to push it through the roadmap via a prioritization process with leadership. This means triaging, sorting and grooming the requests. The grooming part is pretty easy if it's a bug as these can be divided up into:
Blockers, critical and majors will go directly into the engineering backlog as they signal that functionality critical to the purpose of the software is broken. Minor and trivial bugs can stay in the parking lot for the future mainly because there's an interruption cost of fixing every single bug. Next, you’ll need to identify which problems the company should solve in the next 6 weeks, 6 months and 6 years.
The Parking Lot Cycle
We gave a brief run-through of what the feature parking lot concept looks like. The following is a more in-depth process of how the cycle works:
- Use the parking lot as a place to add more data or details into these feature requests so as to increase their confidence score (e.g. anecdotal evidence, market or user data, A/B test results). The parking lot is your one-stop-shop for your galaxy of features and their details. Eventually, as a product manager, you will identify tickets that are relevant for the short to midterm roadmap and isolate those tickets, moving them to step two: Analysis.
- In Analysis you will look further into the tickets, make a business case, set the objectives on what the company could achieve and what's in it for the user if engineering were to build and release those features.
- You will then need to define the scope to achieve the objectives identified in step two. The scope needs to be broken down into ‘must have’, ‘nice-to-have’ and ‘wishlist’ items, allowing you to conduct constructive and collaborative discovery conversations with engineers on what can be accomplished within a 3-month time frame.
- Next, you’ll take the business case as well as the scope to the product leadership team for Prioritization. They will look at all the proposed initiatives and identify two to three that will be given the nod to move forward and get built/delivered in the next quarter. This is where priorities get set by the product leadership team.
- Development begins with UX/UI delivering wireframes, user stories as well as everything needed for the engineers to code.
- You start working towards the enablement of the upcoming features with the marketing team and set up a product launch go-to-market strategy. You engage with support and sales and eventually, the product will launch.
- When the product is in life, you will analyze qualitative and quantitative data to evaluate its performance with real users, identify issues that were perhaps missed as well as look for gaps or new opportunities. All of that new information will go back into the parking lot as new tickets. And then the cycle restarts…
To summarize, your parking lot is where every product idea starts and where every idea is parked until identified and moved along the product lifecycle.
Wrapping it all up
As you can see, there’s a lot that can contribute to a healthy product culture within an organization — from implementing a product-led growth process to creating feature parking lots and eventually roadmaps. There’s a lot to take away in this article, so here’s a quick summary:
There are 7 stages to the product lifecycle management process/parking lot cycle:
- Parking lot: Collect and order galaxy of ideas
- Analysis: Come face-to-face with problems and strategic value to organization if solved
- Scope: Your must-have versus nice-to-have and wishlist
- Prioritize: Decision based on market validation, research and scope
- Development: UX/UI solution and requirements
- Go to market: Prepare for launch with sales and marketing
- In life: Track performance and fix issues
Missed part one of this two-part article series? Don’t miss out! Catch up here!
Thanks to Loren O'Brien-Egesborg for contributing to this article as well as reading drafts and overseeing aspects of its publication. Also, if you have any feedback or criticism about this article, then shoot us an email firstname.lastname@example.org.
- - - - - - - - - - - - - -
Would you like our Product Management Premiere E-book? Visit our Download page →
- - - - - - - - - - - - - -