01 // Product Discovery

After navigating initial conversations, team meetings, and paperwork, we’ll kick things off with a planning meeting. The focus here is defining success and divvying up work, covering questions like:

• Key Indicators: What metrics can be tied to project goals?
• Strengths and Weaknesses: What do you do better than your competitors?
• History: What’s been tried before?

Software is infinitely complex along infinite routes. We’re looking to pair our experience with your domain knowledge to pick the one with impact and value.

History is the greatest source of overlooked value for software that lasts. How did we get here? What have we tried? Why was this decision made? The past may seem like an odd thing to bring up during Discovery, but effective project documentation is just that: A living source of truth, not a list of requirements tossed over a wall to the developers.

Here, our technical leadership starts the ledger. Objectives, needs, wants, and domain expertise become actionable tasks — and a running log for the history books.

Wireframes are also documentation, just visualized. These easy-to-edit, low-fidelity mockups are perfect for demonstrating features and flow before designers and developers do their thing. They’ve routinely been the best way to make sure everyone’s on the same page, so they’re part of every project.

Prototypes are more research-focused and vary project-to-project. If there are any big question marks — a new technology, heavy lifting, novel experiences — we may recommend a limited proof of concept as a way to further remove uncertainty.

We’re pretty good at ballparking an estimate after a chat or two, but pricing is a process — no one can provide precision without a bit of leg work. As the blueprint comes into focus, cost ranges and time estimates will also clear up.