The Importance of Discovery IRL

Punchcard has been working with some clients in a continuous delivery model, where we focus on delivering outcomes on a consistent basis as a super team made up of folks from both organizations.

There are significant benefits to working this way:

• Resources from both organizations are dedicated to the clients’ projects on an ongoing basis, without any unnecessary pause or gaps in progress.
• Working together, our teams can learn from each other’s perspectives on the business challenges, product development processes, and, ultimately, how to deliver better results more efficiently.
• We can continuously prioritize and recalibrate our work as we learn more about the users and the outcome we’re trying to achieve, making our software more effective for our client.

PunchcardOS—Our Proven Service Delivery Framework

Punchcard works within the agile software development process, with some tweaks of our own as we’ve learned and grown over the past decade or so. PunchcardOS, as we like to call it, combines best practices, reliable and scalable technology platforms, and our proven experience. One of the key stages of PunchcardOS is discovery. In sharing the value of discovery, Punchcard Co-Founder Estyn Edwards says it best.

Engaging The User In Discovery

One of our recent engagements with a client was building a product feature for factory recalls. As part of the client’s product suite, there is a feature that involves uploading manufacturer recalls for vehicles on a periodic basis and figuring out which vehicles within the fleet need to be serviced based on this recall list. When you have thousands of vehicles in your fleet, and need to coordinate the logistics of getting these vehicles serviced while rescheduling these vehicles for revenue-generating activities, it can be a lot of work and it is extremely costly to be inefficient.

At the outset of our engagement, the project sponsor and champion had a very clear understanding of how their problem was impacting the business. He knew that the process was extremely manual and that it was taking too much time to get, manipulate, and deploy recall information to the people who needed it.

Because of our sponsor’s deep expertise in his business, their team was hoping to give us their insight to expedite discovery and get to solving the problem quicker. This is the most common request we get from our clients—how can we move towards a solution faster. A natural instinct is to try and get to success quicker by reducing time up front and moving into development earlier. But given our experience and track record, we know that this way tends to lead to software that is solving the wrong problem, doesn’t get used, and ultimately reduces the ROI of the client’s investment.

Though it seems counterintuitive, we know that we need to spend as much time as required to really understand the user, their workflow, and how this problem is impacting them, not just the business itself.

Solving The Right Problem

By following our discovery process and conducting in-depth user interviews we uncovered the root of the problem, something the sponsor and project champion would never have known simply because they don’t execute the work on a daily basis.

The sponsor was right in sharing that the recall process is extremely manual and inefficient, and that there is a lot of room for error because data is brought in from a large number of external sources and then manipulated and actioned in Excel. But their assumption was that the most arduous part of this process was getting the data from its multiple sources into a single source. Through user research, we discovered that this part of the process takes the user 10% of the total time needed to manage recalls. The most time-consuming challenge is manipulating that data so that it can be easily actioned within the fleet.

If we had taken the information we were given, without validating and challenging it, we would have built a product that would save the company a minimal amount of effort—maybe 1-2%. But by understanding the true challenge we needed to solve, we can now build a feature that will save them 20-30% of their manual effort.

You might also like