I’m a product manager for a company that has reached product-market fit and decent maturity.
some of our teams have adopted the scrum framework, and it has been working great for emergent design and value delivery.
We are having trouble managing the more forward-looking flow of work and activities that contribute to the product backlog (just in time) while balancing the delivery of the near-term high fidelity increments in the product backlog.
Essentially the time-boxed vs. continuous flow work (e.g., user research, road mapping, conceptualizing, and sketching.)
Can a few of you share how you’re managing ongoing product discovery and delivery?
TL;DR Continuous grooming of immediate and mid-term needs, and tackling discovery items in sprint-sized spurts. Lean on your UX counterpoint, if you have one, to balance ownership and for help with prioritizing discovery items.
I am currently leading the discovery work within my product team. Near-term items are things that the team has already discussed at least a few times before, so my design effort is usually relatively low and the turnaround time is fairly quick. I work 1-2 sprints ahead of development.
Mid-term items, like things for the next quarter, are usually groomed weekly, but might be groomed monthly. This gives me time to do any initial research if needed, put together flows for feedback, run usability tests, etc.
Ongoing discovery work sort of has peaks and valleys. We don’t expend a consistent amount of energy on this sort of work throughout the year, but I am starting to introduce more structure so that it can happen a bit more routinely. How I have been handling that with my team is mostly in line with Teresa Torres’ opportunity mapping framework:
- identify desired outcomes that you hope to achieve within some reasonable period of time
- use those desired outcomes as a jumping off point for research direction
- insights gathered from research become opportunities
- solutions are the means by which you think you can deliver on those opportunities
- which you can then evaluate through experiments.
For this current phase of work, we are on step 2. I have been prioritizing my efforts in ~sprint-sized chunks, just because it helps me ensure that I’m flowing through our multiple research topics vs. getting too bogged down, and because it’s in line with our regular pacing of work. The sprints aren’t as fixed as the dev sprints though, to give me some more flexibility, but you can definitely plan discovery sprints just like you plan delivery sprints, especially if you have a small team and would like them to all contribute.
If you already have some solutions in mind that are sort of just floating around, you may want to try reverse engineering them to make sure that they ladder up to some outcome. Once you have a better sense of whether or not an opportunity for that solution really exists, you can add it to the backlog.
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.