Among the most important parts of any project, Discovery is where we learn about both the client and the project, and where the client learns about us. Depending on scope and complexity, during this phase we look to establish the following:

• A clear definition of success: are the challenges and goals well understood and clearly defined?
• That we are the right fit for the client: This is where we check that we have the subject matter expertise, project management capacity, and technical skillset to support the client.
• That the client has the commitment and resources to see the project through — particularly when it gets hard (and it will get hard): This is crucial, and often where we provide our most consequential professional advice to our clients.

One thing we’ve learned is that things are almost always more complex than they seem, and that’s particularly true when dealing with technology changes. We know surprises are inevitable, but we are very adamant about minimizing them by taking a very thorough look at the client’s existing setup and processes. This involves:

• An in-depth look at the client’s existing tech stack
• An in-depth look at the client’s existing processes
• An in-depth look at the client’s human capital and internal expertise

Based on what we learned from the previous phases, we can now design a solution that is based not just on where they want to be, but where they are.

• Pragmatic and goal-oriented solution design: Our north star in this phase is making sure that our design solves the business’ challenges and equips them to meet their goals.
• Agile development: Once the initial solution scoping and design is done, we shift our approach to iteration–a process that entails constant collaboration with the client.
• Always on the lookout for surprises: We don’t underestimate — and are very upfront about — the complexities and impending surprises that should be expected in any project. This certainty of uncertainty also drives us to always stay alert for curve balls and be extremely thorough in our planning and discovery phase.

It is common to fall into the trap of thinking that QA and testing come in at the end or near-end of a project. They should never be.

• More than testing: any well-run project should go through several cycles of QA, testing, and changes before going to production. We pride ourselves on not just ensuring that we find and fix as many bugs as possible, but even using the testing process to get a deeper understanding of the app and elevate its performance.
• Heightened client involvement: in these types of projects, unintended consequences are inevitable. It usually takes many testers, including people familiar with the business as well as users who were not involved in the project itself, to identify any deficiencies or issues.