Kicking Off a Big Feature

Your business case is approved and customers are lined up waiting for your new feature. You triumphantly bring the business case and requirements to your engineering team. You are surprised to learn that engineering is indifferent and unmoved about investing in the new feature. What can you do to get engineering onboard with the new feature development?

Discover and Acknowledge the Issues

Meet one-on-one and in small groups to listen to concerns from engineering and delivery teams. Some issues that you might hear:

• Recent re-org has disrupted the team
• Dependencies on outside teams
• Doubts that customers will buy the new feature
• Feature is really big effort
• Subject matter expertise is missing

You can acknowledge these issues and address them as you begin defining the requirements. You don't need to solve the issues for engineering. You do need to construct requirements that enable engineering to solve the problems.

For example, you have prepared a business case that shows many customers are re-using software licenses and this has caused a decline in revenue. Your business case shows a significant increase in revenue if licensing is updated to prevent re-use.

When you speak to engineering about their issues, you hear the following concerns:

• The licensing scheme needs a major rework to handle enforcement and tracking
• The IT team has significant requirements and IT is outside of the product team
• In the past licensing changes were not well defined

With this information, you can

A) define a licensing scheme that evolves from today's scheme in small incremental steps

B) define IT requirements in parallel to the product requirements

C) budget for coordination between the teams

Personify the Customers and Pain Points

Review your notes from recent customer meetings that relate to the new feature development. Prepare a few slides to characterize the customers' situation and the problem the customers are facing without the feature. Cover both the business impacts and the technical impacts for the customers. Do not provide any solution to the customers' problems. Present this material to the engineering team and then listen to their solutions.

For example, your customers are asking for configuration policies to make it easier for mass provisioning of user settings. Engineering is reluctant to design this feature because the requirements are not clear. You recently interviewed 3 customers about their request for policies. One customer needs to change a user setting on a subset of users frequently due to high employee turn over. Two customers have 50 new users every day and the new users have the same profile. In all three cases the customers have to change the same parameters in your APIs many times keep the user settings correct.

When you lay out the problem cases to engineering, they design a user profile and schedule a change in the next 3 sprints. Your customers get an incremental change that addresses a real problem they are having.

Conclusion

Some features need more than the usual business case and requirements definition process to get engineering teams motivated. Listening to their concerns about the feature and adjusting your approach to requirements enables better teamwork. Bringing real customer problems to solve empowers engineering to find solutions that satisfy customers. It can't hurt to follow the lead of engineering on big features!