“Listen to the voice of your customer” was the product team’s motto for the Collibra Data Citizens conference. After all, it was our customers’ – the data citizens – conference. We put what we’ve learned so far about ‘listening’ – and a few new ideas – into practice. We talked less, and focused on answering questions. And, we hosted a hands-on workshop which was all about encouraging our customers to raise their voice.
The Philosophy of Great Software
Great software obviously brings value to the business. But great software does more than that: it creates happy, productive users.
Aarron Walter captures this well in his Hierarchy of Users Need. Great software is first and foremost functional. It has to work to solve a problem. Great software is reliable. It needs to be up and running all the time. Great software is usable. It needs to be easy to learn, easy to use, and easy to remember for all types of users. And then, when you have your foundation right, great software is pleasurable. It delights. Being pleasurable is not seldom about invisibility. A product can delight when it ‘just works’ and is completely frictionless.
Balancing these basic customer needs, and then identifying the key areas to remove friction and add delight, is challenging for any software company. And we face these challenges at Collibra as well. But it is also exactly what makes being a part of the Collibra product team such a fantastic job.
At Collibra, we combined our product management and user experience teams so that each of us touches on these four essentials aspects – functionality, reliability, usability and delight in details – every day! And how do we balance all these requirements? We listen. To the people in the field, to development, and last but not least, to our customers.
Be a Product Manager for a Day Workshop
The goal of workshop was to come up with actionable feedback for two of our key prototyping areas:
- Data lineage and traceability
- Data governance reporting
We chose a hands-on workshop approach so that we – and our customers – were completely outside the normal process and comfort zone. We moved away from the usual support and feature pipeline processes and towards a format where we are more actively pulling – listening for – ideas in a small group. This was a great experience for the customers as well as the product team.
Getting started
After a quick introduction of what’s already planned for the next releases and the long-term product roadmap and focus, we broke into two groups: Team Diagrams and Team Dashboards. Each group was assigned two people from the product team to lead the workshop.
The groups were a good representation of our broad customer base, including customers from financial services, healthcare, insurance, and more. Both groups were familiar with data governance best practices, and had a good understanding of Collibra Data Governance Center.
Nailing down the problem(s)
As mentioned earlier, great software brings values and creates happy, productive users. To go from ‘good’ to ‘great,’ we need to understand problems. If we look at the pyramid of user needs, we wanted to hear about anything that could shake our foundation (functional, reliable, and usable). We were also listening for pain points and moments of friction that we can change so they become an opportunity to delight.
After briefly introducing the topics – data lineage or dashboards – we asked all participants to think about the “problems” they face when using that area of our software.
A problem is not a feature request
This seems like a pretty straightforward exercise, right? It is not. It was quite hard for all of us to think about ‘merely’ what was not good. We have very engaged customers who tend to immediately think about solutions: improvements or new features that might resolve the problem they and others are dealing with.
So we asked our customers to dig a bit deeper and come up with short, one-post-it-sized problem statements based on the 5 W’s: who, what, when, where, and why. This revealed the underlying issues and needs – ones that are all too often hidden behind a feature request in the support system.
Voting and the ‘winner’ problems
After every customer added some problems on the board, we categorized them according to the different categories and created problem clusters. Many times customers ‘seconded’ each other’s problems. To decide which problem we’d further work on, we took it to a vote. Every customer received three votes in the form of a dot sticker, which they were free to allocate at will. They could vote for three separate problems, or put all dots on a single post-it note.
After some contemplation, interaction, lobbying, and at least one attempt to bribe us to get more voting dots, people started to put the dots on the problem statement post-its. For both teams, a clear ‘winner’ problem became visible.
Issue statement
“A problem well stated is a problem half-solved.”
– Charles Kettering,
inventor and head of research at General Motors from 1920 to 1947
While the attendees enjoyed a well-deserved break, the product team set to work at formulating an issue statement for each of the ‘winner’ problems.
Solutions
In the second part of the session, we focused on brainstorming possible solutions, first individually, and then with the entire group. This part of the exercise made it abundantly clear that there are always multiple ways to solve a problem. So, we whipped out the voting dots again. I’m glad to say that in both groups, we ended up with a good understanding of both the problem and the chosen solution.
The two chosen solutions were then worked out in the form of a written user story with acceptance criteria. And as you are reading this, both solutions are already on a fast track through our feature pipeline process.A successful outcome for a great workshop! Our conclusion: we need to do this more often! Based upon the enthusiastic participation and interaction with our fantastic customers, we found that this format is a welcome change from the usual enterprise software process.
From our side, it was extremely helpful to come to a well-defined problem and solution that we know addresses the exact issue the customer needs to have resolved. It was amazing to see the support our customers gave each other during this hands-on session – from voting for each other’s problems, to explaining solutions they already had in place. They are great data citizens indeed!
3 key takeaways for the product team
Lack of knowledge can be a problem too
A few of the problems raised at the session were not actually problems. They were a lack of knowledge of the sometimes mysterious inner workings of our product. The takeaway here is that usability, good documentation, enablement, and allowing customers to share their product knowledge with each other is just as important as product.
Build the ladder, but in the meanwhile, don’t ignore the low hanging fruit
Some issues mentioned were not ‘big issues.’ They are, in fact, reasonably easy to solve. After the workshop, we decided to try and solve a few of these as soon as possible. We’ll be addressing these in a next minor release of version 4 of the product, even thought we are hard at work on our upcoming major release. Why? Because these features will bring immediate value to our customer by increasing and promoting adoption of data governance within their company.
Data governance is about people & process
We need to help our customers increase adoption of our platform within their company. We need to make it easier, faster, more integrated, and fun for your everyday data citizen to ‘do data governance.’ This is certainly a challenge the PM/UX team will keep in mind when working on the product in terms of cool features, better usability, better reporting on usage, and so forth.
Blog Post Contributors: Tom Dejonghe, Erwin Dral, Peter Princen & Ann Wuyts
