There’s a famous quote that people often misattribute to Henry Ford. It goes like this: “If I had asked people what they wanted, they would have said faster horses.” If you heard this one, know that speed was never the main selling point of automobiles — instead, it was the convenience of not keeping a live horse. Ford surely knew this, and he was also very serious about project discovery. In his actual words:
“If there is any one secret of success, it lies in the ability to get the other person’s point of view and see things from that person’s angle as well as from your own.”
This story is significant because it illustrates our approach to getting aligned with our clients’ needs. When conducting project discovery, our goal is to help clients solve their challenges in the most precise, effective, and efficient manner possible. Done right, this phase makes our clients’ lives easier, while providing our teams with a clear picture of objectives, success criteria, key stakeholders, and more.
Discovery is all about asking the right questions, so let’s examine the main questions that we use to help clients set their projects up for success.
What are the business goals?
In my 22+ years of experience in project engineering, architecture, and management, 90% of product teams have a clear vision of what they’re building. The question that sometimes gets overlooked is the why, asked from the business perspective. For this reason, our discovery sessions often include revising the project’s business context.
Asking our clients to revisit their business goals together with us often leads to productive discussion where we can make better-tailored architecture and technology recommendations. In one such case, our team ran a research helping a client decide on the architecture for a PoC of a real estate valuation app.
Featured case study: making business goals dictate technology choices
In this project, we faced a choice between progressive web application (PWA) as the faster, less expensive option and the more feature-complete cross-platform mobile architecture. Seeing that our client’s use cases would quickly evolve to require complex functionality, we advocated for React Native as the go-to option.
Fast forward a couple of years, and the resulting app is used by 47 out of the top 50 US lenders. The app’s main competitive advantages are features like 360-degree camera view, in-app sketching, and advanced analytics, which would have required a complete rearchitecture had the client chosen the PWA option.
Understanding the business context is also crucial when setting objectives for the engineering team and defining the success metrics for the project. That being said, it often makes more sense to view success metrics as a separate matter to explore during discovery.
How do we measure success?
All companies ask this question, but only some ask it early enough. Developers rarely think about it, and for product owners, the key priority is building the product and putting it in front of users. This can lead to situations when, three months deep into the project, project stakeholders realize they haven’t started collecting any metrics yet.
According to a recent survey done by Boston Consulting Group, unclear outcomes constitute the primary reason for project delays and overspending. Failure to define key success metrics and implement systems collecting and measuring them plays into this statistic.
For this reason, our tech leads and delivery managers advocate for starting to collect metrics as early in the project lifecycle as possible. In some cases, this implies developing and implementing dedicated systems enabling the collection of metrics.
Who are the key people involved?
When engaging AgileEngine, you’ll also hear us insist on a single product owner defining and prioritizing features. If you have several people covering these functions, assigning a delegate role is the best way to avoid conflicting directions. A dedicated project owner will also have more availability to act as a point of contact for engineers and designers.
Another critical single-person role is that of an architecture owner. For some greenfield projects or rearchitectures, clients often choose to define the architecture owner on our side. Doing so will get you a tech lead well-versed in providing technology direction and aligning project architecture with your tech policies and business goals.
Who is this for?
This question could be, “Do you have access to users?”, which is something clients often hear when collaborating with our dedicated teams and Design Studio. Setting up user research and future testing may seem too resource-intensive early in the project lifecycle, especially since these workflows can require dedicated UX design, UXR, and, sometimes, ReOps experts.
The good news is it’s relatively easy to augment these roles via on-demand remote consultancy.
We get U.S.-quality work at an offshore price, and the ROI is typically 3 times of what we would typically get from a local development shop. AgileEngine has worked with very large brands, but they can also focus on a small-to-medium-enterprise level.
Source: Clutch
Bringing efficiency to research is a big part of our Lean UX strategy. The ability to engage on-demand resources at nearshore rates has enabled clients to triple their ROI while securing long-term efficiency gains through timely UX activities.
This may be an old stat, but every dollar invested in UX still brings $10–100 in return. When it finally comes to UX testing, you also don’t need to recruit many users — according to Nielsen Norman Group, five is enough to uncover 85% of potential problems.
Where is the finish line?
The same BCG survey calls unrealistic timelines the second-biggest cause of failure to meet project deadlines and budgets. So, how do you ensure the timelines work for both the business and the product team? The first step is to clarify if there are hard deadlines.
Rapid development is part of AgileEngine’s services portfolio, which includes projects tied to product launches, compliance deadlines, funding rounds, or other events. Whenever we deal with projects of this type, we always try to identify if there are hard deadlines or target dates that can impact delivery.
Examples of non-negotiable deadlines:
- Compliance with new standards or regulations coming into effect
- Presenting a new product or functionality at an industry event
- Demonstrating an MVP to investors
- The functionality is needed to win or retain a big customer
- Commitments made on an organization level (e.g. quarterly goals, budget, etc.)
In our experience, tight deadlines can be met by bringing in on-demand resources, which is almost always an option with remote consultancies. If this option is unavailable in your case, considering any potential compromises and tradeoffs early in the project lifecycle is critical. Compromises of this kind include heavier prioritization, reduction of scope, or maybe even quick fixes that will result in technical debt. Tight deadlines can also dictate technology and architecture choices — and even the type of deliverables.
Case study: working with close deadlines
In one client project, a logistics startup engaged us to build the PoC of a cargo tracking solution they could demonstrate to a high-profile potential customer. The project had a very close non-negotiable deadline, which is why we suggested designing an interactive prototype instead of the PoC. The demo was a success, enabling the client to confidently move to building a fully functional solution. Over the years, we helped the solutions evolve into a patented ML-driven SaaS top-listed by Gartner and leveraged by multiple Fortune 500 brands.
Choosing the prototype over a functional PoC enabled our client to meet a tight deadline, which proved critical to the project success. Additionally, this decision allowed the company to avoid overspending on a product which hadn’t yet been validated by the market.
How do we mitigate risks?
The questions we’ve gone through so far help identify some of the more widespread project risks, like diluted ownership, limited owner availability, unclear goals, and tight deadlines. To mitigate these and other risks, team members must identify and communicate them as early as possible.
More examples of risks facing software projects include:
- Suboptimal coordination across teams
- Insufficient budget and resources
- Security concerns
- Poor state of the existing codebase
While it’s relatively easy to identify some risks through communication, some (like codebase quality or security) may require an audit. Factoring in the time and resources for such activities can help project teams prevent critical issues later in the project lifecycle.
Closing thoughts: you can’t take discovery too seriously
Having delivered hundreds of software solutions over the past decade, our team here at AgileEngine has started to view discovery as one of the most strategically important project phases. Doing it right has helped us save up to 90% of our clients’ project budgets and deliver solutions up to 6X faster compared to competitor estimates.
A well-structured discovery framework can help prevent costly mistakes while establishing a streamlined and efficient development process.
Feel free to contact us if you’d like to learn more about our approach to project delivery — and explore how this approach can improve your outcomes.
