AMA: Momentive Vice President Of Product Management, Aleks Bass on Product Development Process

Our product development lifecycle process looks very similar to a double diamond design process but with an adapted approach for our organization. While there are best practices for a product development processes, I've found that there is a decent amount of adaptation and adjustment that needs to happen to customize an approach for the needs of the organization. I've not seen 2 product lifecycles that are the same. At a minimum, a product development process should help reduce friction for the R&D teams, create clarity around what we need to know before we invest, and insight into the variables that influence those decisions. The most mature and refined PDLC programs also create consistant expectations of each role that participated in the product development process, sets criteria for high quality output, and provides clarity on what to do next through each stage. This is extremely benefitial when you think about onboarding new PMs to the team, as well as supporting the growth of PMs new to the role. Depending on the needs and maturity of your organization, you can chooste to implement a light version of this process that focuses solely on alignment and rescource allocation, or lean more into a more detailed process that provides more clarity on activities you expect the teams to execture for each stage. A good process provides time and space for the team to engage in activities focused on discovery, exploration, and time in a particular problem space. In this stage. you should avoid solutioning at all costs. There should be a stage for concept exploration, and I strongly encourage my teams to explore more than 1 concept. Sometimes the first concept we surface is not the best for the job, but inertia and time constraints prevent us from exploring more. I recommend my teams take the time, because it saves us on the rework later. Once a concept has been validated, there should be a stage that allows you to define the high level requirements and start thinking about an experience that would make it as easy as possible for customers to realize value from your chosen solution for the problem space. For me, customer validation of the specific execution is critical, because we are very rescource constraigned on the engineering side. If I can prevent rolling out soemthing that needs major rework, I will. Some organizations are more constraigned on the research or PM side in which case you may use the experience itself for validation. There are many types of product development lifecycles, and you should choose an execution that solves the most prevalent R&D problems your organization is facing. 

Ruthless prioritization. Many organizations are trying to do too many things given the capacity of their teams. I'd rather focus on fewer things that are likely to have a bigger impact than trying to accomplish a larger number of them less well and with less impact to the business and the customer experience. 

I recommend triangulation as much as is possible. Without a QA function, engineering should be checking to make sure from a technical standpoint that what they have built works. Product and design should also be checking to make sure that the experience you have been cultivating is going to create the positive experience for your customers you intend. I prefer to have each of the functions check to make sure we are shipping quality. The most important thing is that QA happens when development is done. And if any changes to the code occur that they are also QA'd. Which sprint it happens in is up to you And your team. 

Our team believes that success metrics have the highest likelihood of driving focus and execution quality when they are tied to our strategy and something we consistently track and explore. Our teams are well versed in our strategy and the related metrics we are trying to move. We, therefore, set our success metrics early in our opportunity assessment phase. We maintain flexibility and will adjust as necessary if new information surfaces throughout our product development lifecycle that suggests we should select different metrics. We bring engineering team leads into the process early. As soon as we have the opportunity assessment to 50% we are sharing it with the engineering leads whose teams would be most likely to be involved in the execution phase. The more context engineers have on what problem we are trying to solve for the customer, why they have that problem, how a solution could benefit the financial or usage outcomes and more, the more engineers are positioned to deliver high-quality solutions that exceed the customer’s expectations, and ask critical questions in the process to make sure we are building the right thing and solving the right problem. The engineering leaders then decide when they want to bring their team in. Sometimes they like to bring them in early so we can do a POC or tests on an experience, while some prefer to wait until we have the work prioritized to avoid distracting their team and reducing velocity. In either case, being transparent about the impact this work could have, and showing engineering team members videos of customers sharing their unmet needs or product feedback calls can be extremely helpful. The more of this content engineers are exposed to, the more likely you are to have a high-quality outcome.

There is an interesting tension here between looking at problem spaces from a variety of angles to make sure you have a sound and differentiated strategy that is worth pursuing and inciting decision paralysis by having too many individuals involved in the process. And the truth is, it depends on the project. I’ll give you a couple of examples for how we have tried to simplify the investment of time and talent for this particular challenge, but it may not work for all organizations. The approaches we take have to be at least a little malleable for the organization or adoption and usefulness suffer. I’ve worked in a few organizations where the investment in exploring a problem space (without a confirmation that investment in this problem was guaranteed for the company) took too much time from key product development functions and even some business and support functions. It felt quite similar to the sensation of dating but never really knowing if this is “going anywhere”. That amount of uncertainty caused a ton of friction in our teams. Some people responded by avoiding the problem space until it was “clear” that it’s prioritized. Some people were so bought in that they went above and beyond to try to convince the organization that it was worth the investment but without crucial data or participation from important stakeholders, so the recommendation never reached its full potential. By the time a decision actually was made (if ever), many people on the team were so frustrated with the project and the level of uncertainty around it, that it took twice as long as it normally would to communicate that it was now prioritized and we were ready to start work on it. This causes a pretty major time delay in some areas. An all around a frustrating experience for everyone that resulted in sub optimal outcomes. Hopefully this example isn’t sounding too familiar to you, but it’s what motivated me to try to leverage our product development lifecycle to create better clarity around who is involved in the exploration of a problem space, what does the exploration of a problem space mean (what activities or information is needed to make a decision), and a ceremony to close the gap of alignment and make a decision on whether it’s something we plan to pursue or not. The first step for me was finding a way to harness the power of the organization at scale for sourcing ideas around problem spaces to explore. We therefore created an intake process that allows anyone in our organization to submit ideas for consideration. They can also tag a customer in the request if it was a customer request, etc. This allows us to get a head start on assessing the opportunity or impact of a particular problem space. The second step was to simplify the information needed to make a decision, and provide clarity and a touchpoint to the team around this stage in the process. I shouldn’t need a full development estimate and wireframes to decide whether or not I want to invest in something that isn’t likely to drive the financial or experiential outcomes our team is targeting. So the sooner you can say no to the project you don’t think will make an impact on your product or business, the less spinning your teams will do and the more clarity they will have on executing on the right things. Here is an example of what our teams will source answers for before a problem space is approved for further work: Our teams (PM, PMM, Design, & Research) answer the following: * Alignment with our strategy - what part of our strategy does it support? (Growth, Retention, Competitive Differentiation, Improved Customer Experience, etc). * Current capabilities - how close are we to having a solve for this space? Is there a workaround? * Opportunity - How painful is this problem and what is the impact to customers if it were to be solved? How will investing in it benefit the company? * Success Metrics - what metrics would be expect to move? On our teams the PM is responsible for the deliverable, but the other team members are contributors with critical points of view and data to contribute. There are potentially many other sources of support within the broader organization that are included depending on the problem space and their unique purview, but we try to keep the teams small so that we don’t slow down the process. Once the team answers these questions, they present their opportunity assessment to our product leadership team who then decides if this is a problem space we will invest in, and provides support via resource allocation, prioritization, etc. Of course these questions are not enough to fully answer the question - Is this worth investing in? Things like capacity, level of effort, which solution we choose, and many more can have an impact on whether something is worth investing in or not. But this allows us to structure a meaningful touchpoint in the flow of the process that can remove problems we likely won’t invest in early enough so they don’t create unnecessary drag on the team. We have this same opportunity further down the line when it’s appropriate to look at the recommended solution, or the investment in development. In many ways this process is like a funnel. There are stages and things you can remove early because they just don’t make sense, but there should be more opportunities to change your mind sprinkled thought the process as you get closer to development.