Product thinking and validated learning
As part of moving to a product centric approach, one of the often-ignored aspects to consider is the escalation of commitment to bad ideas…
As part of moving to a product centric approach, one of the often-ignored aspects to consider is the escalation of commitment to bad ideas or products.
Killing off a project is usually far easier than retiring a product, there’s often a lot more of a supporting system in place for that product to exist (often within an ecosystem). We want to learn as quickly as we can, so this means knowing when to cut your losses and knowing then you have delivered enough value.
We’ve seen countless examples of products that have been over engineered with too many features that very few people want or need. We then see the same companies become more focused on user experience and then go through a radical simplification of their products — however they risk alienating their power users in the process. Sometimes upsetting some users to satisfy others is a trade off that makes sense, other times it does not.
Look at the history of the MS Office suite (now called M365) and the menu systems / ribbons in MS Word, Excel. I don’t envy Microsoft and the trade offs they’ve had to make for an established product. This is even more apparent when you see new products enter the market such as Google Docs, Notion and Air table which significantly change how the products work and interact with their users. They don’t have the same legacy and backwards compatibility that a company like Microsoft does. How does MS create a new MS Word killer? I don't think they can, someone else must.
Kill your darlings
In psychologically safe organizations, this means reducing or winding down effort once sufficient value has been realized. How often do you see organizations stop projects or products because they have delivered enough value, or because they weren’t able to achieve market fit.
Google is one company who kills products on the regular. Sometimes a good idea is just a good idea, Google Glasses was ahead of its time, the technology and form factor wasn’t right — Google would rather release a product and learn from failure.
In contrast Apple does the same but in complete secrecy until they feel they have a truly competitive product. If you have the product expertise and the quality of people that Apple does you can take risks like that.
Apple doesn’t win through innovation; it wins through creating products that solve people’s problems in a way that their customers love. They have the patience and smarts to exapt other people’s innovation to their products.
What does this mean for your organization?
If your organization is going through a big expensive Agile Transformation, you may not know it yet, but you are about to grind to a halt in 12–18 months unless you have addressed a few critical capabilities.
Learning to plan together rather than in isolation, create product roadmaps that convey strategic intent rather than a delivery commitment. Aligning plans around OKRs that are beneficial to the organization rather than your department is key here.
Learning to deliver your products in incremental steps that each deliver value (this is conceptually hard and requires discipline and practice). Good is better than perfect, feedback is better than delayed.
Learning to think about your products from a user / customer perspective, have people in your teams who get product, who get user experience. UX isn’t the UI design so don’t confuse the two.
Learning to use OKRs for good rather than because you can make them up and measure them. Less is more when it comes to OKRs, few OKRs means an organization and focus and align on a common goal. If your goals reflect departmental silos, you are not doing OKRs properly.
Learning to limit the amount of work in progress at both a portfolio level and a team level. Flooding teams with too much work is how you end up not delivering anything. Focus on helping teams get things done rather than starting new things. Look to reduce work item age.
Learning not to start work you don’t know how to do; this is a major risk. If teams don't know how to solve a problem, invest in a spike to prove out how to solve a problem, that will provide a time bound period to focus on solving a problem rather than trying to deliver. If you don’t stop to learn and figure things out you will not be able to finish work you’ve not done before. If you don’t allow for time and reflection, you will have inferior product quality because you are not building learning and improvement into the process.
Focus and reflection
Demmings: Plan, Do, Study, Act (PDSA) cycle is really all agile aspires to be. If you don’t go through the full cycle, teams are not able to improve or learn.
Teams will keep working the same way as they did unless they have the time, safety, and space to reflect. Having the next ‘sprint’ breathing down your neck is also not helpful, and, in some cases, Scrum has enabled management to get excited over terms like velocity, story points, burn downs etc.
In an ideal situation, teams reflect after each piece of work, they pull work from a queue / backlog, and they finish the work before starting more. That means helping each other out rather than individually being busy. This is the opportunity for individuals in teams to learn new skills from each other, this helps create the breadth of the t-shaped individuals we often talk about.
The greater the breadth of knowledge in the team, the more the team can work together, rather than as individuals handing over work. I have seen this happen when there’s a business analyst and a tester and the rest of the team are engineers. The business analyst and testers are busy at certain periods of time but not throughout the work and so if they want to stay busy, they start pulling work the rest of the team isn’t ready to work on yet.
This is also where refactoring, automating, and re-architecting come into play. If teams aren’t doing this regularly, they are digging themselves into a deeper hole that they won't be able to get out from.
If you are a manager or leader, make sure that your teams are taking the time to reflect, learn and improve. If they aren’t doing this regularly, this is a reflection on you as much as it is on them. This is often a recipe for burnout — human beings need time to learn and change, that isn’t possible under duress.