Regulated SaaS / Public Safety
A regulated public-safety platform where features kept shipping but nothing moved forward. The root cause was a permission system that had never been properly designed. Every workflow disagreement traced back to it.
Guardian Alliance Technologies had built a cloud platform used by law enforcement agencies to conduct regulated background investigations. The platform was growing, new clients were coming in, and engineering was building. But investigations were stalling, features were being scoped and dropped, and the same conversations kept happening in circles. Non-technical stakeholders knew something was wrong but could not name it. Product and engineering knew it too, but every time they tried to fix one thing, something else got more complicated. The underlying cause had not been clearly mapped.
The platform had multiple agency user roles, like supervisors, investigators, in addition to the applicants, each of these roles had different permissions and a different part to play in the investigation process. This is a role-based access control problem, and it is one of the most common places enterprise software breaks. An Admin, a Manager, and a Read Only Auditor are not supposed to see the same screen. They need different views, different available actions, and different visible data, even when they are looking at the same underlying record. Guardian’s platform had never been designed around that principle. Instead of assigning permissions based on who the user actually was, the product had been built with a role switcher, a workaround from the prototype stage that had never been replaced. I mapped the full system: all primary agency roles, the mixed-permission users, the workflow states each role could act on, and where those states created contradictions. I documented the gap between what sales was requesting, what the product could deliver, and what would be required architecturally to close it. I established a framework for measurable objectives so any future work could be evaluated against outcomes rather than just shipped features.
For the first time, the organization had a single coherent picture of how the product actually worked versus how it was supposed to work. I gave leadership the language to have the conversation they had been unable to have: not because the conversation was political, but because nobody had the shared vocabulary or shared picture to have it clearly. The decision was made at the leadership level, with full understanding of the tradeoffs, that the product was not going to scale by adding features on top of the current architecture. The foundation itself needed to change. That was uncomfortable. It was also the only accurate answer.
Enterprise SaaS / Cloud Computing
Three user types with completely different jobs to do, sharing one interface that had never been designed around any of them. Assessed the product, mapped the permission layer, consolidated redundant features, established the design system, and rebuilt all three experiences. Eight months later, acquired by ServiceNow.
Healthcare Technology / Clinical AI
AI was being built into radiology workflows at GE Healthcare, but the product had been designed around engineering assumptions rather than clinical reality. Rebuilt the worklist architecture around how radiologists and clinicians actually work.
Consumer Goods / Enterprise
Hershey had employee research for their enterprise intranet but nobody to turn it into a product. Translated it into an information architecture grounded in employee mental models and a prototype that surfaced the decisions the client had not yet made.
One conversation is enough to know if this is the right fit.