Scenario 3: Product/Tech Collaboration
Your engineering team estimates a requested feature will take 3–4 weeks of development time, which could delay a major plugin update. You believe this feature is important for users.
Question
How would you approach the trade-off discussion with engineering? What frameworks or communication strategies would you use?
Before starting discussions
Here is the information I will bring to support and enable the discussion.
- I’d remind myself of the cadence of releases, and what is planned for the forthcoming release.
- I’d challenge whether it’s acceptable for these items to be delayed in favour of a new additional feature?
- It’s important to understand how delaying the release impacts the business. I would bring estimates for our key metrics like predicted revenue and estimated signups for both situations.
The scenario outlines that the estimation has taken place, so I’ll assume that the features of it are fully scoped out.
Trade off discussion
To enable this trade-off discussion, I’d run a workshop to collaborate with the engineering team.
Opening the discussion
I would begin the discussion with the problem: That by implementing the currently estimated feature, the release date would be delayed. I’d like to work together to see if we could find a way to deliver the desired outcome to the user and reduce the delay to release.
I’d also share why I think it’s important to deliver it, using data to back up what I’m saying.
Team impact
I would ask the engineers to share what the team impact of changing the planned date is, since they are the ones who work on releases. We want to minimise any additional work to them.
Re-prioritising the feature set
I would using the MoSCoW framework to review the proposed set of features.
For each deliverable, as a team we’ll work through which are must-haves (fundamental), should have (important, but less valuable), could have (nice to have but not important, improve the user experience) and won’t have to identify which elements are fundamental and which are nice-to-haves can help trim excess fat.
Focusing on which deliver the desired user outcome and align with our key/North Star metrics, we will vote on which should be in each category. This allows everyone a fair chance to share their opinion since more introverted people may not feel confident enough to speak up in a large group meeting.
Once the feature set has been grouped, we can re-estimate how long each of the must-haves and should-haves will take. As a team we might then break it down to focus solely on an MVP in this release, with a view to building it out in future releases, compared to delivering a better experience in one go with a little more time taken.
Final decision making
It is important for the engineers’ opinions to be heard and we have should have a general agreement.
Having listened to all the feedback, ultimately the PM should take final decision but it should not be in stark contrast to the opinion of the other stakeholders.
The decision should be communicated to the wider team as any change can impact GTM strategy, customer support, sales, etc.