How Shortcut Uses Holistic Feature Planning to Reduce Unwanted Surprises

Have you ever been surprised at work? Was it a delightful surprise or an unpleasant surprise?

• Delightful surprise: getting a positive shout-out from a teammate 🥳

• Unpleasant surprise: realizing you need to delay releasing a new feature because of previously unknown complexity 😢

While there are always going to be some unknown unknowns when planning a new feature, what if we could reduce the number or scope of unknown unknowns? That's where Holistic Feature Planning comes in.

When planning a new feature, it's easy to focus too narrowly on the new things to build, and to not account for the relationships to other parts of your product or technical architecture. When one primarily focuses on the new thing, it can lead to underestimating the time, level of effort, and complexity required to ship a feature to customers.

When one incorporates a more holistic approach to feature planning, it provides a space to "zoom out" and proactively account for the wider scope of changes needed to support a new feature.

So: how do we plan holistically at Shortcut?

We have recently started using a list of questions to ask ourselves across Product, Engineering, and Design:

Scope of Work Questions

• Aside from the views we are directly changing, are there any items that are indirectly impacted by this feature and need to be considered and updated?
• What are the areas of potential complexity for which we should add extra time?
• Are we touching any areas of the codebase with a lot of tech debt? How do we want to approach this tech debt?
• Are we modifying any "default" patterns or data?
• This question is relevant if your product generates any default data for new users.
• Which tracking events do we need to modify, and which tracking events do we need to create?
• What changes will need to be made to our QA testing suite?

Release Related Questions

• How can we break down this feature into "mini milestones" that we can release to different audiences at different stages?
• Examples of release stages: internal to company, beta release, percent rollout, general release
• Which feature flag(s) and targeting rules do we need to support these release milestones?
• We use LaunchDarkly for managing feature flags. You can read more about How Shortcut Uses LaunchDarkly!
• Which sections of the feature are "nice-to-haves" that aren't required for a general release?
• We can still plan to work on these before a general release, but good to know which requirements are suitable for deprioritizing should we be running low on time.
• Are there any organization-wide initiatives that will compete for our time?
• Examples: end-of-year reviews, company retreats, hiring 

And finally–although not strictly a planning question–another important question to ask is: How can we celebrate as a team directly after the general release? It can be tempting to immediately work on follow up items or switch directly to the next item on the roadmap after releasing a feature, but it is important to celebrate your wins and take a moment to recognize a job well done!

What questions do you ask yourselves when planning out features? We'd love to hear what has worked well for you!