Markets evolve fast – products have to evolve even faster. Working in the product team at TrustBuilder is very much like playing in the Premier League: high intensity, high pressure, high quality. We took a tour of the grounds with Kurt Berghs, Product Manager at TrustBuilder, to understand how products are initiated and designed and how new features are prioritized. And how the customer is always front and center in all developments.
Where do the ideas come from to build new features?
Kurt: There are always plenty of ideas to build new products or features. Our customers are our most valuable source of input. Our account managers talk to them constantly and they bring fresh ideas and requests to the table. Anyone at TrustBuilder can also come up with feature requests. Our development team regularly proposes ways to make our products better and more complete. As a product manager, I keep a close look on market evolutions and how our competitors are reacting to demand from the market.
But the base, in all this, is our own strategy and vision, which translates into a roadmap. That is based on our long-term view of where the market is headed. It doesn’t make sense to add a feature that has no place in our roadmap.
Plenty of ideas then, but do they all become products or features in the end?
Kurt: We always make a careful evaluation. First of all, you have to see if there is a market fit. Is there a real interest in the product? Will a company be willing to spend money on it? Secondly, we check if a feature can be productized and sold to multiple customers. It’s no good developing something that fits only one specific customer.
Sometimes product proposals also need to be checked by Legal, for instance for anything that is GDPR-related.
So you don’t just jump on any proposal and have it developed?
Kurt: Certainly not. There are some pitfalls to avoid when thinking about new products and new features. It’s easy to fall for what is sometimes called ‘Obsessive Sales Disorder’, where commercial people claim they need this one extra feature to convince a customer to buy. That’s how you get fragmented products. ‘Strategic swelling’ is another trap, where you let a product try to do too much for too many users, and where you get distracted from your vision.
Are some requests treated with priority?
We determine the priority using different criteria: can we sell it? Can it be productized? Is the market ready for it? What is the benefit? We balance cost with benefit. As an example: last year we launched the Service Catalog, which is a huge benefit to both our customers and our consultants. We bundle multiple Identity Providers (IdPs) and applications into the Service Catalog. That means we don’t have to integrate the IdPs over and over again, which is a significant cost saving.
Customers always come first
Prioritizing seems like a very important, but also a very difficult part in the process, right?
Kurt: Absolutely, you need to avoid developing things where you don’t know how much development will cost and what the benefit will be. Sometimes new features seem very interesting, but fall off the table when you have looked at them from all sides.
Obviously, we can and need to react quickly to other requests as well: legal requirements that pop up, security vulnerabilities that appear. In that case, the request goes straight to Product Development to have the issue solved immediately. Our product owner Yannick will put it on the development sprint planning. The same goes for small features. Customer needs always come first in deciding these priorities.
So once a feature gets the green light, what happens next?
Kurt: Once you have made the decision to go ahead, the feature goes to the product management board. As a product manager, I sit on that board together with the technical product owner, the CEO, and our COO. There we decide on the priority a feature gets, the budget, a buy, build or partner approach and the next steps, including whether or not it needs a mockup or not.
Design-first development for optimal UX
Why is a mockup important?
Kurt: First you need to know that we always work ‘design first’. Before a feature moves to development, we want to decide with the UX designer what a product will look like. We want to see all the front-end screens and how a customer will experience them. That is key in delivering products: they must be easy to use and intuitive for the customer.
In most cases, the design leads to a clickable demo. Not only does this make it easy for the analyst, but also means we can show something to everybody involved. Sales and Presales can demo it to prospects and customers. Getting user feedback is key in the development of a feature, as it may lead to changes, that ensure a better fit of the product with market needs.
Are mockups only interesting for customer feedback?
Kurt: No. Mockups also help the analyst decide what needs to happen in development. The analyst translates the design and the requirements of a feature into storyboards, epics…
The analysis allows us to calculate exactly what the workload will be to get it developed. Until the design is done, we only know at high level what the workload will be. Then we can split it up into sprints and epics which allows us to calculate the exact number of man-days. Once we know the exact cost, we go back to the Product Management Board for a final go-ahead.
It also allows faster development since they there’s no doubt anymore on how the user experience should be. Developers don’t need to worry about the visual aspects anymore and the QA team has better guidelines on the behavior of the product. Most importantly, when the delivery is final, there are no surprises between business requirements and technical delivery.
And then, finally, development starts?
Kurt: Yes, the product owner will plan the sprints. At that moment DevOps will be informed, especially if something needs to change in the infrastructure or architecture.
As soon as the analysis is done, the test plan can be drawn up, based on the requirements that come out of the analysis and the design that has been made. It’s important that Testing is involved early on.
Once the development and testing has been done, DevOps gets involved to see how best to automate the implementation part. Product Management checks whether all the required functionality is there, and if everything works as planned.
We work in 2-week sprints. We need to be able to demonstrate an epic after two weeks. The demos are given during the sprint planning. This may lead to extra feedback.
Once Product Management has given the go-ahead, the product goes to DevOps to take care of releasing it. If the feature is written for a specific customer, we will also do acceptance testing in the customer’s environment.
Who decides on the timing of the release?
Kurt: That’s the job of the Product Management Board. We are always working in parallel on several features. When important features come together, we release them at the same time, under a new product number, for instance TrustBuilder 10.4 or the upcoming 11.
By that time, the technical release notes will have been written and are validated by Marketing. That’s when Marketing can start informing the customers and promoting the solution to the market. To ensure that everyone knows the new features, training is organized for everyone involved. Sales already had some training when they showed customers the clickable demo, but after the full training, they can really go out and present the product to the market.
And then the circle can start all over again?
Kurt: That’s right. When customers start using a new product, this will spark new ideas. You see that it’s all about the customer: they come up with ideas, we develop those ideas into new products and, based on the feedback from customers, we continue to make the product even better.
