Authored by Mike Thone and Paul Gebel
To those in the digital product space, the term “Discovery Phase” will likely wash over us like many of the other oft-touted buzz words of our industry. But a healthy discovery process allows us to understand product-market fit and identify key user needs. What’s keeping us from incorporating this valuable learning into our products? We believe it’s either ignorance, intuition, or inertia that stands in the way of successful discovery.
Delivering production-quality software is expensive, and doing this work when we’re not even sure it’s what the customer wants or needs can be a huge waste of resources. Regardless of whether it’s intentional, every digital experience involves the Discovery process. Whether you do it purposefully in preparation or accidentally after the fact, is the decision you need to make.
Performing effective discovery involves recognizing and overcoming these barriers.
Barrier #1: Ignorance
The availability of information limits decisionmakers’ effectiveness and efficiency as they set out to build new products. They may be tempted to begin building before their plan has been vetted. Once an idea begins to take shape, stakeholders are eager to begin development right away. Without first understanding key user needs and assessing product-market fit, a team could easily spend a lot money building the wrong things and solving problems their users do not have.
Product leaders must combat the affliction of ignorance, whose symptoms manifest in an unbridled eagerness to jump right into the hands-on-keyboard project work. It’s important to first identify the business goals, competitive benchmarking, user research, architectural assessment, and (most importantly) user experience outcomes.
The antidote for ignorance is education. With Agile methodologies, modern UX practices, and an MVP approach, product managers can take an iterative approach in which we adjust our plan as we learn more about what will be successful.
What story do you tell those who battle ignorance of discovery? The risk of not knowing is greater than the risk of increased cost.
Barrier #2: Intuition
The mantras of the fatally intuitive design leader are: “I know what I want” and “I know how to build it.” The BIG IDEA is theirs, and it’s perfect. By kicking off an effort where leadership has unknowingly fallen into confirmation-bias, we enter confirmation-based discovery.
The team may be working to identify product-market fit and user need, but if their findings stray from the leader’s vision, there’s sure to be unnecessary arguments that hinder your progress. These projects burn time chasing final sign-off and burn money with scope creep as inconsequential details are included.
With effective discovery, it’s important to identify and address the biggest risks first. We want to create something valuable to users, viable for the business, and feasible with our technology and development resources.
When leadership insists you build their vision, the antidote is to work with them to identify the true problem they’re trying to solve. When the actual pain point is discovered and discussed with the stakeholder, they feel listened to, even understood, and become less attached to a singular vision. This approach allows your team the space necessary for data to inform your approach.
What story do you tell those who already have all the answers? “If we want our users and their needs to be present in our minds as we’re creating our designs, we need to regularly see them.”
— Jared Spool, Maker of Awesomeness at UIE
Barrier #3: Inertia
Some teams don’t plan for discovery and end up fitting it in as they go with a slow grind of trial-and-error, dissatisfied user feedback, and budgets that aren’t lining up with initial projections. They’re chasing release dates and aren’t allowing new data to influence their approach.
Still other teams confront the opposite problem. They invest months-worth of time trying to figure out every single thing before they start development. As a result, they lose sight of the end product they envisioned. They’re unwittingly creating a continuity problem, where some folks are concerned only with vision and others only with execution. Such an approach leaves little room for a team to influence the product in real time.
We don’t always enjoy the luxury of dictating when to let our teams stray from the plan; but what happens when you discover something so significant that it threatens your success?
Isn’t this precisely the type of challenge Agile is supposed to address?
This is a planning problem in which management has lost its way by growing too attached to a particular feature set or timeline. Any change that affects the annual roadmap becomes a battle.
The antidote to the paralyzing effects of inertia is continuous feedback that influences the roadmap. Discovery and delivery must work together continuously, and leadership needs to reserve space for incorporating key learnings to deliver a successful product.
What story do you tell those who realize too late that discovery was improperly or incompletely done? It’s never too late to change tack and turn the ship around!
Embed Continuous Discovery Into Your Products
A healthy team will build continuous discovery into their products so that what’s built is valuable and meets users’ real needs.
When ignorance is the problem, trust that an iterative approach will allow a team to build momentum and learn continuously. When intuition is the obstacle to success, focus on identifying the real problem and allow data gleaned from effective discovery to influence our solution. When inertia prevents us from incorporating useful learning into a product build, examine your process and allow continuous feedback from discovery and delivery to influence decisionmakers.
It’s far cheaper to discover that an approach isn’t viable than to build a product that fails to thrive.
Discovery vs. Delivery. https://svpg.com/discovery-vs-delivery/
Product Discovery: Pitfalls and Anti-Patterns. https://svpg.com/product-discovery-anti-patterns/
Fast Path to a Great UX – Increased Exposure Hours. https://articles.uie.com/user_exposure_hours/
Mike Thone is an Interaction Designer (Ux/Ui) at ITX Corp. He earned his BFA degree from The School of the Art Institute of Chicago. Mike specializes in end-to-end user experience design for web applications. His passion for delivering high-quality products has allowed him opportunities to serve many roles on a cross-functional team, including Product Manager, Scrum Master, Front End Developer, and Lead Designer.
Paul Gebelis Director of Product Management at ITX Corp. He earned his BFA and MBA degrees at Rochester Institute of Technology, where he currently serves as Adjunct Professor. A veteran of the United States Navy, Paul’s experience also includes extensive project and product management experience and consultancy. At ITX, he works closely with high-profile clients, leveraging technology to help solve business problems so they can move, touch, and inspire the world.
Interested in learning more about Effective Discovery? Contact ITX today. We’re excited to work with you!