In this #mtpcon SF+Americas 2022 keynote, Scott Williamson, Former Chief Product Officer at GitLab outlines 7 signs you may be in a bad product system, while giving practical and actionable advice as to how you can make meaningful changes.
Watch this video or read on for key highlights from the talk.
- Bad product systems result in unmet commercial expectations
- Work to clarify direction, ownership, and outcomes
- Give feedback and work to improve the system you’re a part of, or plan to assess your next one
Scott begins by describing how 50-95% of ‘product launches fail to meet commercial expectations’, explaining that, while ‘product land is complex’, product systems ‘don’t always reinforce the right kinds of behaviours, the right kinds of activities to increase your odds of success’. He outlines 7 signs a product system may be broken:
Everyone starts with the solution
Solution-first thinking is natural, Scott explains, stating ‘we always think we have the answers’. However, he continues, oftentimes we may end up solving the wrong problem, or making assumptions that lead to lack of adoption or require re-working and redevelopment, as ‘human intuition is wrong more than we want to admit’.
Scott recommends interrogating assumptions through qualitative interviews with 5-10 target users, in order to validate ‘5 different things about the problem’, while ensuring it is ‘repeatable – that you can find multiple times, that’s acute, and painful.’ Once you can recognise patterns emerging, you can be confident you’re investing in the right thing and can progress towards a solution.
Planning is dictated
When product teams are not in control of their planning, and initiatives are enforced by executives, sales, or large customers, you will hear things like ‘the CXO asked for X’, or ‘a big customer X won’t sign if we don’t do this thing’. Dictated development is rarely scalable, Scott says, warning of repeated reworking, ‘long delivery times due to custom code’ in an increasingly complex product, manipulated by ‘one-off’ investments.
Creating an Opportunity Canvas for every new idea can help navigate this, Scott says, recommending the template as a way to frame and assess initiatives. It documents the problem statement, target users, current workarounds, success metrics, and allows people to offer a first version recommendation, while helping you understand the value, in real monetary terms. Having ideas standardised allows you to prioritise by impact and justify why an ‘idea is actually the best way to leverage your team’s time’.
Product direction isn’t clear
An unclear company or product strategy can lead to confusing product direction, breeding misalignment across teams, and outwardly affecting adoption and market share.
Scott advises creating and distributing an Amazon 6-pager within the business, outlining product strategy, ‘your challenges, and how might you overcome that in a really succinct way’. The document becomes a tool used to invite feedback and ‘tease out misalignments between yourself and product leadership, and execs in your own team’ and additionally, can help onboard people to future initiatives.
Ownership isn’t clear
A growing backlog of items relating to ‘product no one really owns’ and references to ‘this nasty dependency on team X’ indicate unclear areas of responsibility. Unless resolved, team ownership issues may result in overlapping or repeated project work and missed deadlines, particularly when development touches shared services.
‘Define a charter’, Scott says, recommending a group exercise which draws boundaries around the products and services each team maintains and works on. He advises that even for technical teams, a charter is most effective when ‘rooted in customer value’, helping clarify ownership across the business.
No one is sure what progress and success look like
It’s vital to effectively measure outcomes and track progress in order to understand success, Scott explains, warning that ‘you can end up with a real misalignment between the teams that build stuff, and the teams that are trying to run the business and sell things’.
He advises teams to adopt KPIs (Key Performance Indicators), ‘usually 1, but maybe a handful’ as ‘a way to demonstrate the value and contribution to business results’. With teams clearly owning KPIs, business decisions and product direction can be discussed in terms of moving metrics, rather than ‘arguing about whether you should go with line 24 or line 48, in a very deep backlog’.
Everything is a priority
‘You’re always going to have far more to accomplish than your bandwidth allows’, Scott says, explaining how capacity is at a premium when you’re working to expand into new markets, building new products, and scaling systems. Continually adding priorities, however, can be disruptive to planning and may ‘reduce velocity, create chaos, and just create this constantly changing environment’, damaging morale.
Scott recommends adopting Product Themes, which sit as memorable strategic groups of initiatives on a roadmap, classifying the ‘50 things in your backlog’. Themes can be used to help make prioritisation decisions and highlight misaligned requests, allowing you to say ‘this is what must get done, and I can’t afford to sacrifice that’.
No focus on career development
Poor development opportunities or companies that don’t have development plans in place often have a higher likelihood of attrition, which then ‘puts more pressure on the people that stay’.
If you can’t rely on leadership, Scott recommends creating your own career development document, outlining your goals for the next 2–3 years and then plotting milestones as to what skills and activities you will need to gather to get there, connecting this also with short term initiatives and projects. Take this to your manager to align on, or look out-of-house for mentorship and training opportunities.
To stay or to go?
‘I hope you feel empowered to try to improve your own situation and the system you’re in’, Scott says, referring to his experience at GitLab, which employs an ethos that everyone can contribute to the product system. Improvements take time, he explains, noting an increase in employee productivity after 2 years, with better relationships, greater knowledge and context. As a result, Scott says ‘I generally advise people to stay so that they have a better chance at really having a big impact. Because what you want over your career is just stacking examples of impact on top of one another – that’s where you learn’.
That said, Scott acknowledges the best choice can be to leave bad product systems, which may stunt your career, teach bad habits and lead to less impact. Reflecting on his own career, Scott says he’s found success through ‘choices to optimise for learning’ as opposed to making decisions just for title or compensation increases: ‘it always worked out for me, because I learned faster, I made more impact, I had more wins’.
Assess your next system
To finish, Scott recommends looking back across the signs of bad product systems to make sure you ask the right questions when assessing the next one. Ask ‘what’s your product strategy?’, ‘how does the product development process work?’, ‘how’s success measured?’. Look at development frameworks used, the way the company reviews and prioritises work, as well as understanding the charter for your next team.
Finally, ask yourself: ‘is it clear, unambiguous, non-overlapping and rooted in customer value?’
There’s more where that came from!
Explore more #mtpcon SF+Americas 2022 video content or use our Content A-Z to find even more product management insights.
Comments 2