Reduce, Reuse, and Recycle your products

Balancing competing customer requests can be a challenge, but it's even more of a challenge when your business uses platform managers in addition to product managers.  At a previous employer I was the lead product manager on a platform that saw over three million users per year. On top of my platform the business had constructed six different product lines targeting different market segments, each with their own product manager.  

When I arrived, one of the chief struggles for the team was balancing the requests from the six different product lines.  Each line wanted slightly different features on different timelines, so the engineers spent all of their time sprinting trying to put together functionality for each and every request.  As a result, virtually no time was spent working on the platform itself and it was crumbling under crushing technical debt.

At one point I had three different product lines asking for APIs, two product lines that were asking for single-sign-on functionality, and a line that had even contracted with an outside firm because they couldn't get what they needed in-house!

That experience taught me a valuable lesson: Reduce, Reuse, and Recycle your technology.


Try to see across products and customers to see the commonality amongst the requests. By reducing engineering scope in general, you can give your team more time to build thing the right way. In the above example I did this by looking at the SSO requests.  The two products had timelines for completion over a quarter apart and they wanted to use different SSO providers.  Through negotiation with the product managers, I was able to standardize on one SSO framework, set a completion date equidistant between the two timelines, and greatly reduce the amount of work my teams had to do.


Reusing existing product work is a great force multiplier that can help you make huge leaps from a functionality standpoint while conserving your strength. At the employer in this example, I did this by looking at the aforementioned APIs and SSO requests.  I was able to build a “new user” API for one of the product lines that was then reused by two other lines later on.  It was built in a generic enough fashion that they could all make use of it, even though their products were slightly different.


When you build something, keep extensibility in mind. When writing specs for an import process, walk the fine line between cutting scope and keeping it loose enough to be re-used for other purposes. Let your engineers know when this might happen. I do this by mentioning it as a nonfunctional specification in the story like "when designing this import process, keep in mind that we may want to reuse it to import team or company assignments in the future, not just user assignments."  You don't have to be precise, but just that sentence can give your engineers enough knowledge so they know how to build your product for maximum benefit.