Leadership and Training
The People Who Write the Content Now Build the Product
How SEQTEK rebuilt product building from the ground up for a research client, turning a process that took months into one that takes less than a day.
The client
Our client is a research company whose products are reports. Decades of published research sit behind each one, and organizations around the world buy them to make better decisions.
The shape of that business is worth understanding, because it is what makes everything below matter. A customer buys one or more products. The individuals each product is about are enrolled and matched to whatever that product's method calls for. Their data is gathered and scored, the scores become a report, and the report goes back to the individual. The product is what is sold. The reports are what the product is made of.
The problem
Building a single product took months, involved a lot of people in necessary roles, and always ended in the same place: a developer writing code.
A product owner would start with marketing to work out the look and feel of the report. If a large customer wanted something custom, a consultant joined the conversation too. Marketing designed the product, the product owner took the design back, and then it went to a development group, who wrote the code that produced the report.
That last step is where the months went. Every report had code behind it. A new product, or even a change to an existing one, meant engineering work, so every product waited its turn in a development queue. Three to six months was normal.
The content had a similar problem. It lived in spreadsheets, a new one for each product, spread across the company alongside marketing language and everything else that had been written over the years. Content was distributed rather than centralized, so finding the right source and confirming what it belonged to was itself a meaningful part of every build.
The approach held until custom reports were needed at scale. At that point the economics stopped working.
The solution
Our client had studied the problem carefully before funding the rebuild, and they wanted a partner who was not close to the existing system. Someone who would bring a fresh read on it. We had already worked together on another product that went well.
SEQTEK spent the first months of the engagement learning the business through a discovery phase. They gave us access to a test environment so we could walk the full customer journey ourselves, as both a report recipient and a customer administrator. We also walked the entire flow of how the current system worked, how new products were built, what a build actually cost in time, and what a better version might be able to do about the bottleneck.
Working with their technical team, we broke the platform into three possible areas: product building, content management, and scoring. Together we agreed that the first phase would cover product building and content management, both of which have since delivered significant value to the business.
They had an early mockup of how the new product might work. Discovery surfaced requirements that reshaped it, so we restarted the design collaboratively with their design team, working from the business need rather than from what a new application could do.
A similar moment came later, and it turned out to be the most important decision in the project. The default path was to build report elements in code, product by product. It would have worked. It would also have put every future product back in a development queue. The alternative was general purpose: a grid container that users lay out themselves. Both options went on the table with the math attached. Six months for the three products in hand and the same again for each one after, against four sprints that looked like a slowdown and were not.
Alongside it, the two teams settled roles and responsibilities early, so decisions could be made quickly and in the open.
1 dayto build a product
down from the three to six months every product spent waiting in a development queue
10 minto assemble a product from an approved spec
the remaining time is review, not engineering
The impact
The platform is now three applications behind one login, each with a distinct job. Content builder is where product language is written, edited, and translated, feeding a content repository built to serve as the central home for the company's content. Product builder is where a product is assembled from graphics, scales, and report elements, pulling its language from the content repository, with a stand-in recipient so a report can be checked while it is being built. Product viewer is what the recipient sees when the report reaches them.
Building a product no longer requires writing code. The product owners and content editors who know the material assemble it themselves. What took three to six months now takes under a day. Assembling a product from an approved spec takes about ten minutes, and the rest is review.
The content repository changed something quieter but broader. Instead of hunting for spreadsheets and working out which product each one belonged to, the company has one normalized place where content lives, which changes how it moves into everything else they do, not just reports.
Some parts of the journey are unchanged for now. Marketing still designs the product and consultants still work with customers on what they need, and that stretch of the process is the next one the teams plan to take on.
Two years in, we continue to work at a rapid, iterative pace. Once products started coming out of the platform, the conversation changed. Their team now spends its time asking what else the platform can do, with the first products built on it moving toward the people who receive them.
Technologies
- Squidex
- Angular
- C# / .NET
- API-driven architecture