Problem discovery

We don’t just build features, we build solutions to customers problems. Ideas can come from customers or internal stakeholders but the aim of this phase is to understand what problem we are solving for our customers. We need to dig deep and understand customer problems while asking ourselves: Is the problem unique to one customer or will it benefit many? Does this align with our strategy and who we are? As part of this, we also strategically trade off various opportunities against one another given that resources are pretty fixed.

Our product has a variety of different users that differ by their position within the organisation (their hierarchy) and also by their department, which means the problems and needs of these users are quite different. For example, the insights the Marketing department needs to know in order to make data driven decisions are very different to the insights a General Manager or CEO needs to know. The problem that we originally ran into is that we were interviewing the wrong people which resulted in false negatives. What we’ve come to realise is the need to understand who the feedback is coming from and then reach out to the right users from a variety of organisations to ensure we’re getting a consistent picture across a specific group.

Solution discovery

Once we have validated the customer problem and have agreed that this is the opportunity we want to pursue, then we start the process of solution discovery. Product, design and engineering work together on possible solutions, we create wireframes & prototypes which we then test out with customers (where possible) to ensure the solution we have come up with A) will solve customers problem B) we will be able to build from a technical perspective and C) aligns with our business model, strategy and future growth.

Something that we discovered is that designing for data products is quite different compared to other software products. When showing customers prototypes we couldn’t just show made up insights, we had to use real data that was specific to that customer. The reason being is a) we need to ensure the designed insight works for the real life nuances and messiness of real world data and b) that our customers can understand the insight and will make real life decisions based on this insight. We refer to this acceptance criteria as an “actionable” insight. Last year we designed an entire process around this and if you want to take a deep dive into the problem space – check out our Design Director’s talk on the topic Beyond Interesting: Designing For Data Products.

Solution delivery

Once the solution is validated the next step is to enable an effective and efficient delivery of the solution. This means the engineers responsible for delivering this work need to be completely aligned and understand what’s required from a product and technical perspective. In practical terms, this involves breaking the solution down into deliverable pieces and creating relevant tech documentation. The key piece here is to decrease the risk of the technical ‘unknowns’, to investigate and dig into the code as and when needed before we start building the solution.

Something that works extremely well for us at Dexibit is to have the engineers who are going to be building the feature break the work down and create the tickets together. We have experimented with the practice of having a single person creating the tickets for the entire team but we have found that this led to a lot of confusion and the need for further ticket clarification during the sprint. Needless to say after 2 sprints and 2 rounds of retros, we went back to team ticket creation.

Software delivery is not a science, it’s an art. In reality the delivery process is not as linear as the diagram above and various discoveries during the process can result in the problem going back into a previous phase.

From my experience, the top reasons for failing to meet customer expectations are related to lack of or poor systems and processes… rather than the employee. Over the past year we’ve had an absolute blast working together with engineering to create a process that enables us to not only improve the value we can deliver to our customers but to also enable and empower our teams to do what they do best.

I feel very humbled and inspired by our journey to date and can only imagine the heights our delivery process will get to as the business grows and develops.