Leadership Buy-in
Based on my extensive research, I know we could create immense value for our customers if we shifted the focus of this project beyond a data collection system, to a full suite of case management tools. This increased the scope of the project, but would position us miles ahead of our competitors.
This dramatic shift in scope and focus required leadership approval. I walked the leadership team through the entire proposed workflow, and tied each decision to the data I had collected in the research phase. I received enthusiastic approval to move forward, with 5 developers for 6 months.
After seeing that first demo, our CEO sent me this personal message:
“I’m a bit speechless. It’s one of those rare moments I get to have as a founder. I sort of realize that a teammate gets what we’re trying to do, and even extends the company’s mission even further (and more incredible) than I originally conceived / imagined. Keep up the amazing work. You continue to be a real pleasure to work with, know what to focus on, a beautiful eye for both visual and UX design, and can simply “get shit done.” You made my day brighter, thank you for that.”
Agile Product Management
For the next 6 months, I worked as the acting Product Manager overseeing the work of 5 developers.
The system would be reviewed and we would be approved or rejected as a vendor according to strict deadlines, so changes had to strictly account for scope. Some hard choices had to be made about the priority of different elements and behaviors. I had to make these prioritization decisions based on my user research, and communicate those decisions back to developers, internal stakeholders, and the Camden team.
As 5 developers simultaneously tech-designed their way through the many designs and requirements, technical constraints and legacy code threatened to put our delivery date in danger. I worked with the developers to creatively rework requirements within the constraints of the system to ensure we were never spinning their wheels on problems that don’t have big impacts.
Modular and Iterative
We built iteratively and improved as we learned. The prototype was being refined through testing with users and in collaboration with the Camden Coalition’s program design team. The entire dev team had to be kept abreast of the tweaks and changes that came out of prototype testing.
This was a complete redesign of a huge portion of our existing system, and multiple views, interactions, and features had to seamlessly pass information and states across screens. Changes to one interaction would have repercussions and update many other screens and views. For this reason I used a component-based modular design system.
Stakeholder Communication
This would touch every part of our system, so every department had a major stake in the success of this project. To successfully launch this project, I kept internal and external teams informed on progress, scope, and changes through
- weekly check-ins with external customer teams
- communication up to leadership on the progress my team was making
- trainings for each internal team that would touch this part of the system — sales, customer success, product support
- product documentation ranging from highly technical to high level, tailored to various teams’ needs
Data Analysis
Metrics and logging were not an afterthought in this project. I tested and refined the reporting output that would be used in the final analysis of our product’s efficacy.
Our vendor approval was primarily tied to how well our new product area could perform data collection and produce accurate and insightful reports. I designed reports that helped case workers allowing them to refine their methods, focus their time, and see their effect on the community.