What works in one place doesn’t work in another.
Everyone has worked with a newbie who thinks they can take what they did at their last company (where they certainly may have been effective) and make these best practices “fit” in their new company.
More often than not, this doesn’t work. Nor do people appreciate it.
To find success in product delivery, you have to learn about your new environment and adapt the tools from your past to accommodate new variables. Not every old tool or approach is going to work in the environment, pace, team personas, objectives, products, etc.
What does adaptability look like in practice?
- Dig into the current “what” and “how.” Look at all the variables to learn how people and projects are currently operating.
- Discuss approach. Talk to the team on how they want to operate moving forward and what tools are preferred. Absolutely show past examples/tools, or have new, modified templates ready for review in this process. But don’t be tied to these prior methods. There is a solid chance they won’t “fit” a second time around.
- Distill MVEverything. Narrow down what work you have time for with the team based on what you must accomplish to meet the objectives.
- Devise a plan. Get buy-in from the team and stakeholders so everyone is moving the same direction.
- Deliver.
This mindset of adaptability sets you up for success, and increases your likability across teams, stakeholders, and customers. One great example of putting this into practice is when it comes to deciding between sprint or kanban.
To sprint or kanban?
Do you always choose sprints?
Are you anti-scrum?
Should you go somewhere in the middle?
Below are some of the factors I use to decide the best approach:
- What does the team prefer? e.g. The team is junior-mid level and could benefit from in-depth grooming and planning poker or estimation sessions for a 2+ week sprint model.
- What is best for the client and/or stakeholders? e.g. Priorities shift constantly but predictability is still important so it’s better to have increased flexibility with shorter 1-week sprints.
- What is best for the users? e.g. Getting value out ASAP is of utmost importance, and your team is very senior with reliable code, so lean into kanban (or something in that vicinity).
Have a situation where you aren’t sure what is the right tailored approach for your team, environment, and company goals?
Chances are you’ll fall back on solutions you’ve used in the past. Sometimes that can solve the problem but you need to watch out for solution bias – it can block you from finding a new solution.
Avoid solution bias
Too often, people jump to a tool, process, or document from their personal toolbox before learning what a specific situation, problem, or task needs.
Don’t jump to the last thing you used, the first solution that bubbles up, or what is most comfortable based on past experiences. Take (the minimum amount of) time to assess the situation and plan the right approach with adaptability top of mind.
You never know where you’ll land. And chances are, it’ll be different from what you think or are used to.
I stumbled across this quote when researching solution bias last week: “Solution bias: Achilles' heel of a Product Manager.”
I don’t know Serge Bajic but his words from this article last year definitely carry a lot of weight and are worth elevating.
Whether you’re seasoned in product delivery or new, everything above is going to come up again and again. And with so much new AI technology, an adaptability mindset is more important than ever.
If you don’t immediately fall back on methods from the past you might discover a new way to solve a problem that saves huge amounts of time and money. That's ultimately why "adaptability" is a crucial product delivery mindset.
Follow Kim on LinkedIn
Kim uses LinkedIn to share her thoughts on product delivery, prioritization techniques, and enterprise product development and design.
Follow and engage with her here.
