Case Study
Building a Successor While Supporting the Product Customers Still Used
Managed PublicStuff lifecycle work while shaping Service Request Management (SRM) commercialization, configuration, and launch. I connected customer continuity, product direction, and the practical work of moving to a successor.
Jump to a section
Delivered capability
A successor product backed by commercial and customer-transition work.
SRM gained commercialization strategy, roadmap and launch material, and configured workflows. PublicStuff customers continued to have a product owner focused on lifecycle planning, defects, and incidents during the transition.
My contributionI worked across product strategy, configuration, customer feedback, and lifecycle coordination. Engineering, operations, security, and customer-facing teams contributed their respective parts of the transition.
- Starting point
- An aging service-request product still had customers relying on it, while its successor needed a clear product and commercial direction.
- What changed
- The newer product had a commercialization and configuration path, alongside coordinated support and transition planning for the existing customer base.
Project scope
The work behind the result
Commercialization strategy, roadmap, and launch assets
Multi-year transition covering retention strategy and feature parity
Defect prioritization and incident management
Two products with different obligations
PublicStuff was an acquired customer-relationship and service-request product with an established customer base and aging technology. Service Request Management, or SRM, was the successor direction.
Existing customers still needed a dependable product while the newer offering needed commercialization strategy, a roadmap, and launch material. My work crossed both responsibilities, from day-to-day product health to the longer transition.
Keep the existing product workable
I managed PublicStuff end-of-life work through a multi-year platform transition. The scope included retention strategy, feature parity, defect prioritization, and incident management.
I worked with operations, database, and security teams on the sequence of technology updates. Lifecycle planning had to account for what customers were using now, including the operational issues that could not wait for the replacement product.
Make the successor commercially coherent
For SRM, I worked on commercialization strategy, roadmap, and launch assets. I researched competitors and pricing, then developed pricing and business-case material for commercial and product leadership.
I also worked on application and inspection configurations with cross-departmental integrations. That connected the product proposition to the workflows agencies would need to use.
Use customer feedback to shape the transition
A pilot agency became an important part of the replacement work. I ran recurring working sessions that showed the latest build, gathered feedback, and informed the next iteration.
The customer conversation helped distinguish a feature list from the workflows people depended on. Feedback informed configuration and product direction, while feature-parity work kept the transition grounded in the existing experience.
The result across the lifecycle
The work produced SRM commercialization strategy, roadmap and launch material, and configured workflows. PublicStuff lifecycle and operational work continued alongside it, including retention and feature-parity considerations.
The central product judgment was how to advance the successor while meeting obligations to current customers. It required commercial decisions, technical sequencing, and direct customer understanding to stay connected throughout the transition.
Skills demonstrated