How customer pain points turn into Webtrekk solutions.
A post from Webtrekk Junior Agile Coach
This is the third installment of the Dev Blog series, posts written in the language of programmers.
In the 11 years since Webtrekk was founded, an increasingly complex architecture has emerged. Our solutions empower customers to access raw data, dissect this data however they want and use it to launch fully automatic marketing campaigns.
Meeting the demands of sophisticated and dynamic markets calls for a state-of-the art product development process.
On the one hand, this process must provide enough flexibility to cope with constantly changing requirements of that specific market segment (including the customer needs involved). On the other hand, sustainably solid structures are required in order to ensure a continuous value chain.
Here’s a quick overview of how Webtrekk’s development process works.
Conception and implementation
About four months before a specific development period, all Webtrekk employees are encouraged to contribute ideas for use cases. These ideas – which come from the C-Level, sales teams, consultants, marketing and of course developers – are then collected by the product owners (POs) of individual teams. Aligned with the Head of Product Management, they decide on which use cases should be delivered.
Next, the POs define “Time Invests”. These reflect a sort of cost-benefit analysis for each of the chosen use cases and are designed to prevent over-engineering.
Delegates of different departments then gather with delegates of feature teams to form concept and mock-up teams. These virtual teams construct basic technical and visual drafts with a special emphasis on user experience, usability and customer pain points.
The resulting drafts are the foundation of user story workshops, which function as sanity checks and help address some of the burning questions around development: Which requests can be delivered in which timeframes? What is still negotiable? How much benefit can be gained, and what are the opportunity costs?
Because workshop participants come from multiple teams, we are able to identify dependencies between teams in advance to the actual implementation.
What it looks like
The “Dynamic Box” is a recent example of how this process turns concepts into solutions.
The Dynamic Box began as an idea from a Webtrekk consultant, who himself got the idea after speaking with a client.
The client was able to generate reports and show them via email and PDF, but there was still something missing when he had to address non-analysts: They always wanted to see the actual object being analysed, whether it was a video or form or new design.
There was no way to visiualise these objects, requiring the analyst to flip back and forth between the report and different parts of the company's website.
The consultant’s idea: Find a way to put the things being analysed into the report.
After hearing this recommendation, the PO talked with Sales and Consulting to determine if this sort of feature would be indeed relevant for a substantial group of current and future Webtrekk clients.
When the answer came back an emphatic Yes!, the Analytics team ran with it.
Throughout the development process, the POs worked hand-in-hand with Consulting to optimise the Dynamic Box. To give it all the features that clients needed, and not to stuff it full of things that were technically possible but not all that relevant. Embedded videos, styling options (to incorporate corporate identity, for example), external and internal links and images were all included.
Meanwhile, drawing functionalities – which might have been fun but probably not so useful – were nixed.
After a few months of development and testing, the Dynamic Box was launched as part of the Mercury Release and is now available for all Digital Intelligence Suite users. And those presentations that used to require flipping back and forth between the report and the website got a lot easier.
Why all this effort?
This multifaceted conception and development process – which stretches from the original idea to the user story workshop to product creation – ensures the market viability of the product while also creating a sense of ownership among the developers.
Thanks to the direct involvement of developers, this process also tends to provide a higher level of detail for the entire planning process. Developers, as experts on products and their functional details, are in a perfect position to reveal dependencies and foresee technical issues.
We always prefer the direct dialogue between departments and stakeholders. However, with more and more people involved – developers as well as product managers – informal exchange kept decreasing. With this setup, communicative exchanges have been integrated, formalised and made scalable.
And more, better solutions have been brought to life.