RapidIdentity, Identity Automation's core offering, was undergoing a total frontend rewrite and redesign. It had to. It was written in Flash and Flash was being deprecated by everyone. Flash was no longer a viable technology.

The company was growing. Revenue was up dramatically. A company had recently been acquired whose technology would dramatically enhance our market reach. Things needed done and more contributors were required. An infusion from Venture Capital made this all possible.

Identity Automation had resources but they also had an imperative : if their product did not work in a web browser the day Flash was disabled - they had no customers and were in breach of innumerable contracts. If we didn't make the deadline - the business would suffer. And that suffering would most likely be fatal.

All product features available in new codebase. No lost customers. Integrate acquisition features. Consistent UI design.

Identity Automation was in the identity management business. Our focus was controlling and auditing access to digital resources. A resource could be an Instagram account or a Word Document.

RapidIdentity was a hodge podge of functionality designed by accretion by programmers. The companies standard strategy was to sell something, build it, then sell it again.

I was hired as a Senior Software Engineer. My primary task was rewriting the companies core product. Simultaneously, I supported bug and feature requests in the old product.

I coordinated with the backend team, QA, and sales on a daily basis. Later in my tenure, I led a weekly meeting with the CTO, Director of Engineering, Engineering Managers and two Product Managers.

One of my first goals as a member of the frontend team was identifying who are users were and how they used the product. The interview process had revealed that no one was truly sure. Our bottom line wasn't directly affected by our users - they were locked in. The general concensus was it didn't matter - the users that mattered were the ones with whom sales had a relationship.

My first act as an employee of IA - quite obstinately insisting that analytics were absolutely necessary.

I segmented my data by user type. We had a different relationship with each. These were legal, professional, and for the sales staff - sometimes personal. I was able to determine user type based off both permissions and hierarchy inherent in the project.

For example, in a school setting, an end user would have permissions for one module, a manager user would have a hierarchy under them, and an IT user would have permissions to at least three modules. Consultants and internal employees would use special licenses.

Revealed internal users were not really using the alpha. Letting staff know I knew rectified the problem immediately. This led to an essential increase in bug reports and feedback. I was not a Pokemon trainer, without help I could not catch them all.

Revealed browser and OS usage. No customer was using internet explorer. We safely deprioritized bugs identified by QA. We maintained QA on IE and put issues into a special bucket in case we obtained an IE7 customer.

Revealed some clients were not using the product AT ALL. Support reached out, issues were identified and entire accounts were saved.

Revealed features were only being used internally. We could safely deprioritze new development. I took that time to recruit internal testers and focused on pre-development UX activities to improve my co-workers workdays.

As our rewrite gained capabilities we began to prompt end users to try our beta product with a prominent button that allowed them to return to the old product. Users that participated in the beta became part of a tracked cohort, users that then reverted became part of another one.

Whatever action users took upon reversion was of supreme interest - a safe assumption was that the new interface had failed them in some way.

There were early wins but their was also a need for patience. A majority of our customers were schools - this meant there were usage cycles. We had to monitor usage during the school year and during the summer - when implementations of our software often took place.

We had to wait 10 months before we could draw our final conclusions. Meanwhile we had a product to build!

As part of our agile process, we created stories and estimated them. We tracked our velocity and knew what a reasonable pace per iteration was. Every two weeks, we showed new, functional software.

We had reliable metrics. We made and estimated stories for the rest of the Rapid Identity. We knew for certain we had a problem.

We had over twice as much work as we could possibly finish. We had one year to finish - and over two years worth of work.

This problem was exacerbated because the company was B2B. New, highest priority features were being added. As a B2B company, sales were made on promises for features implemented on timelines. Like most companies, trading risk for reward was part of the package. At any point in time, we could be tasked with a new top priority feature.

The company made an open call for solutions - on the surface the problem seemed intractable.

We had over twice as much work as we could possibly finish. We needed more people but we believed in the Mythical Man Month. We'd added two developers in the past year and directly measured dips in velocity. If we doubled our body count - we would have thrice as much work than we could possibly finish.

Leadership made an open call for solutions - on the surface the problem seemed intractable.

I now had a years worth of data and the data showed a way.

Keeping our obligations to customers in mind, I broke the product into what was owed to each.

We had a legal obligation for accessibility to our end users. To our manager users, we owed continuance of any tools they relied on. While not a legal issue, it was in our best interest to not force them towards another tool.

To our IT users we had a legal obligation to allow them to continue to generate auditable assets they could then provide to end users.

To our internal and consultant users - we owed nothing but paychecks.

To our stakeholders we owed obedience but also reality. We had to say, 'No'. I opened hard conversations, I had to sacrifice popularity for the product.

With this amount of obligation it was impossible to reach our deadline without some sort of risk. But with prioritization - this risk could be mitigated.

To do this - I also had to consider user behaviour.

Our product had 8 massive modules, one with a pure user focus, six with various audit related functionality, and one massive configuration module to rule them all. The backlog could be arranged along two measurable axis : the user for that feature with consideration for actual user pathways.

Assets on the end user pathways was a must complete at high quality. Additionally, these assets must pass accessibility. Developers and QA worked together to make this possible.

Assets on the non-configuration IT pathways was a must complete at high quality. Configuration pathways were a must complete at low quality.

Assets on IT pathways during the school year were a must complete at medium quality. However, anything from a configuration phase could be deprioritized with hooks put in for alerts. IT users was comfortable contacting support and we could be proactive identifying attempts.

Assets on internal users could be completely deprioritized. Flash was dead but internally we could conduct workarounds our clients could not.

Segmenting and analyzing user pathways presented us with a massive win. Our biggest most complex module, a module we had developed training for, training that ran with a full roster

Everything was prioritized but even what remained to be done was still around twice what was accomplishable. We needed