I Don’t Have Time for Product Discovery
"I don't have time for Discovery"
The above quote is common…especially from teams that have long planning cycles of 8 weeks or more.
After working with over 200 teams, it’s clear these long-term plans get frequently interrupted and changed.
The feature requests inside these plans often have short 1 to 2 sentence descriptions.
This is not enough information for the team to understand the request.
When they probe for more information, it’s clear the requestors don’t deeply understand the request either.
Yet, leadership insists the planning must go ahead and teams admit (to me) to just making up estimates.
Then when the plan is set in motion, around the 4 to 5 week point, leadership often changes the plan anyways.
This can lead to re-planning the remaining weeks.
All of this time spent on the longer term planning cuts out time for testing and validating ideas.
The “doom loop” of planning
Teams describe a few reasons why planning cycles get longer and longer.
Every time there's a defect or an unpredictable event, leadership asks for more planning to avoid another unpredictable event.
Other teams (sales, marketing, executives) rely too much on long range dates and features to close sales even though they are rarely achieved as written.
When plans don’t work, executives ask for more planning (which doesn’t seem logical). This results in additional processes around planning. Sometimes, executives hire entire departments of employees to run the product/engineering processes.
Spend less time planning and more time validating
For Product Leaders, think about how time is spent on long range planning and make sure it isn't eating up time for Product Discovery.
Instead of planning harder, teams can plan smarter.
They can repurpose planning time into product discovery time.
When teams spend time validating an idea, they understand it more deeply…define it better…and their resulting plans are more reliable.
From talking to teams, planning seems to break down around the 4 week mark though it depends on the team and the type of product.
Before 4 weeks, product plans seem fairly reliable. After 4 weeks, they tend towards being made up.
How you can make this change
Start by discussing a culture change.
Usually, engineering leaders dictate the need for longer planning cycles.
So any changes to planning processes will need engineering buy-in.
Assemble a representative, cross-functional team and address the pros and cons of long term planning.
Make sure to include the hands-on keyboard engineers and architects who make estimates on long-term projects.
Find out what is working and what isn’t working with the current planning process.
You may need to meet with individuals one on one if they are not comfortable discussing negative feedback in a group setting.
Try to reframe the discussion around what’s important to the business not just what’s important to engineering.
Try to bring data about previous launches to provide context to the discussion.
Separate the theoretical from the actual so teams are intellectually honest about the success of the current process (or lack thereof).
Most times the consensus is long term planning is mostly made up but that leadership still wants it.
At some later date after these conversations, a change occurs.
Most often, the change starts with one fed up PM who won't show up to the long term planning meetings. Or who refuses to create plans so far in advance.
This starts a meaningful discussion opening up the byzantine assumptions that led to such long cycles.
It can be risky for one person to not show up to a planning meeting.
To date, none of these “rebellious” PMs have been fired.
And most of them no longer have to do planning beyond 4 weeks.
This frees them up to do more Product Discovery.
Jim coaches Product Management organizations in startups, scale ups and Fortune 100s.
He's a Silicon Valley entrepreneur with over two decades of experience including an IPO ($450 million) and a buyout ($168 million). These days, he coaches Product leaders and teams to find product-market fit and accelerate growth across a variety of industries and business models.
Jim graduated from Stanford University with a BS in Computer Science and currently lectures at UC Berkeley in Product Management.
