TPM Balancing Business & Technical Requirements

Every project requires technical ground work including architectural design, hardware and software setups, software updates and upgrades, building Continuous Integration and Continuous Delivery pipelines, test automation, logging and monitoring etc. TPM may find himself/herself in a tussle with product management and business to balance business and technical requirements for successful delivery. Explaining the value of each technical item to business takes effort and may feel burdensome at times.

Here are some guidelines that a TPM can use in interactions with partners to prioritize technical stories:

1. 60/40 or 70/30 Rule: Many organizations have already declared a guideline of 60/40 or 70/30 for business and technical stories. This is your best bet as a TPM to negotiate getting technical stories into the sprint. You may deduct the 40-30% team capacity or average velocity while prioritizing business stories for the sprint. This saves the time and effort in explaining each and every technical requirement to business.
2. Build a $$$ Use case: Technology requirements need to be converted into direct $$$ value to be understood by product managers and business counterparts. Let’s take an example, there is a Cluster upgrade that is required for the application to scale to the anticipated load. Ignoring it will result in degradation in customer experience which may impact the revenue. TPM should be able to articulate the whole scenario with projected numbers along with the pros and cons.
3. Analysis/Trouble Shooting: Many technical requirements like logging and monitoring are directly related to the team’s ability to find root cause of potential issues and resolve them quickly. TPM may need to have data on the number of incidents and average resolution time and how that can be reduced by implementing additional logging or monitoring.
4. End of Support Software: Software projects are implemented using many software tools and services. These tools and services may have end of life support dates. This means that software provider will stop proving support for a version beyond a certain date. TPMs need to build the case on their upgrade and potential issues and impacts to the project/business in case issues prop up in unsupported versions.
5. Leverage Security/Privacy Champions: Security and Privacy champions are assigned to make project implementation and delivery compliant to organization and regulatory standards. You can leverage these resources in your meeting with business counterparts to prioritize security and privacy related requirements.
6. Give Real Life Examples: News websites frequently cover security breaches, poor application performances, website crashes etc. Having some real-world examples handy will help you build the case for technical and non-functional requirements.
7. Show Flexibility: While every project wants to use the latest technology and tools, it is also true that many technology upgrades may be postponed relative to the urgent business needs. This may result in short term overhead for the technology team but frees bandwidth to address immediate business needs. Showing flexibility builds trust also gives some extra credit points to the technology team which may be used later.

TPM is a customer/business advocate to the engineering team. TPM needs to make sure that technology team remains focused in making business successful at the marketplace. At the same time, TPM should have enough technical ability to know which technical requirements need prioritization and which ones may be delayed. This ability to see the project through multiple lenses and making best decisions for the project success makes TPM role unique and interesting.

Share your experiences below on what worked for you in getting the technical requirements prioritized in a timely manner. Let us know what you learned from the experience and what will you do differently again.