Context: When I started in my current role, I inherited a team using the Scaled Agile Framework (SAFe) operating model. I quickly realized, that this SAFe framework was creating big problems in the team. The disconnect between product management, developers and designers, interfacing almost exclusively through a technical product owner, created a textbook feature factory. Problems mounted. The ‘us vs. them mindset’ meant that building and shipping anything was painfully slow. Developers and designers were risk averse, avoiding experimentation and only concerned with shipping as many features as possible with no concern about outcomes. The unpleasant working environment resulted in high turnover - nearly all developers in a six month period during the worst time. And there was a even bigger problem: the entire operating model was incapable of supporting new product discovery. Everyone, including me, was unhappy with the situation and it was obvious a big change was needed.
Approach: During the unpleasant business above, I began reading extensively about alternative operating models. From my studies, I proposed something radical to heads of development, design, and my business unit: kill the SAFe model and adopt the Product Operating Model instead. Although everyone wanted the team setup to change, there was still hesitancy. However, all leader stakeholders agreed to support the shift. One major reason for support was that the team had ditched the SAFe model during our work on the COVID detection solution - to great effect! We thus had a clear demonstration of what change could look like.
Adopting the product operating model meant the following: implementing the cross-functional product trio setup, (see below), in which each trio works toward OKRs or KPIs directly tied to user/business outcomes. Each OKR/KPIs is owned by the entire trio, not any individual team member. Furthermore, product delivery and discovery would take place in parallel as discovering new products became a strategic imperative.
Leading a transformation: the product operating model
Impact: In my experience, most people don’t want to work in feature factories - they want meaningful work as part of a supportive team. Fortunately, one immediate impact of adopting the product operating model was a surge in team morale. People were motivated to collaborate more closely and cross-functional relationships grew stronger. The team atmosphere became much more collegial - something that I believe substantially reduced turnover.
The first big test of our new model came when developing an antibody data searching and profiling solution. Not only did our new ways of working help us create an impactful solution, but we did it much faster than our old processes would have permitted. Similarly, the product model supported not just new developments but also helped deliver strong commercial results - a significant achievement given post-pandemic disruptions to the customer and user base of our products!
Adopting and implementing the product operating model wasn’t without challenges. For example, we struggled early on to define clear areas of ownership in the product trio setup and initially tended to use OKRs as a ‘fancy KPIs’. However, my team has continued to learn and improve over time.
Aside from the impact on my team, adopting the product operating model had other impacts as well. For example, using OKRs directly influenced the rest of the business unit to adopt them. Our business unit’s success with OKRs itself contributed to OKRs being rolled out to the entire organization. I’m grateful my team’s experiences and results played a part in this ongoing organizational transformation, especially as the product operating model itself directly correlates with successful, high-impact product functions.
Successfully adopting and implementing the product operating model is one of my biggest achievements. Reading about change management is one thing, but it’s another thing entirely to actually do it.
Context: After some changes in the C-Suite, I received an explicit mandate from senior leadership to launch new products, which was both exciting and daunting. One reason for adopting the product operating model (see above) was to accelerate new product development - a key strategy for transformational business growth. An ecosystem of markets meant there were many opportunity spaces to explore. However, while the product operating model gave my team a good foundation, we still needed methods for new product discovery. We needed tools to rapidly test and assess ideas for product-market fit.
Accelerating product discovery
Approach: The first step was surveying various product discovery methodologies. I myself stumbled on and recommended Opportunity Solution Trees (see below). Others proposed the Confidence Meter and ICE (Impact-Confidence-Ease) scoring for prioritization. With these frameworks and a stockpile of testing methods, I could guide the product team’s efforts to assess the Four Big Risks of product development: desirability, usability, feasibility, and viability. Commercial viability is of particular importance since any product ideas must also deliver business success. Establishing evidence-based product discovery processes, based on multiple quantitative and qualitative methods, gave us a foundation to dive in with rapid research and testing. Another key element was to establish clear kill/pivot/persevere criteria at each testing phase before experimentation.
We soon built up an ‘experimentation backlog’, wherein we tested product concepts with increasing rigor. For example, high-risk ideas were purposely tested with the simplest and least time-consuming methods (e.g., a smoke test with a landing page and simple CTA). As each opportunity gathered stronger evidence of product-market fit, we’d then shift to validating commercial viability (e.g., the service obtainable market). Once out of the testing stages, we’d have solid evidence to support go-to market strategies for new products.
Impact: The new methodologies quickly made an impact. Adapting and implementing established discovery frameworks allowed the team to test multiple product ideas simultaneously while also effectively managing existing products. The evidence gathered allowed us to assess how promising, or not, particular product concepts would be. My team has been able to assess new product ideas much faster than we had imagined before adopting these new methods.
There’s a myth that testing and research is laborious and time consuming, but what’s worse? Investing some time and effort to validate an idea or investing time and effort to launch a product and have it fail in the market because it doesn’t deliver enough value to customers? I’m proud to say that my team has killed many seemingly promising product ideas. Empirical evidence gathered from testing and research made it clear that some ideas would never achieve the required levels of product-market fit.
An experimentation approach to collect empirical evidence for product discovery has created other benefits as well. To start, my kill/pivot/persevere decisions, as they’re evidence based, are transparent and justifiable, which is particularly important when dealing with both senior management and other stakeholders. Business investment cases are also stronger precisely because of the validation behind them. Also, the approach has allowed me and my team to build up strong competencies in product testing methodologies - something I’d consider critical for a successful career in product management. As in other cases, my team’s work has served as a model for other product teams aiming to adopt an experimental approach to product development.