Building for Change
Our team of Product Managers works alongside you to build and deploy software differently than you have before. In the process, you become enabled to do this work self-sufficiently in the future. Your team learns cutting-edge technology and best practices the best way possible: by doing it. The knowledge you absorb while working with Pathfinders is just as valuable as the finished project itself.
To engage with Pathfinder is to learn by doing. Your team members pair with Pathfinders Product Managers, working side-by-side as much as possible to collectively build a great product. We strive to find the right set of practices that fit inside your organization. One result is world class Product delivered efficiently and cost-effectively. The other result is that your team is now ready to do the same high-quality work all on its own.
We assess your current full Product Development Life Cycle - from start to finish. Using a process that we have found to be repeatable and successful we will start to make recommendations across the different phases, including strategy to ideation to discovery to build/measure/learn. We evaluate and help guide you through the inputs and outputs of each phase. For example, generally the inputs to Discovery are a lightweight opportunity assessment which conveys “what problem are we trying to solve” and “how big is that problem.” This gives the context needed in order to validate the hypothesis during Discovery. What we see happen as a result of this include:
Shared understanding between the business units and product teams of the problem (the “problem”)
Shared understanding of the value of the problem (the “benefit”)
By understanding the problem/benefit the team will include instrumentation in the design/development so that we can measure if this has the impact that we expected. And inform future strategy!
The team avoids over-engineering the solution because they are unsure about what to build generally leading to faster delivery.
The teams know what to build when requirements leave room for interpretation, which happens isn’t a bad thing.
The team now knows when they are done. For example, should/can we solve for 90% of the issues with 30% off the effort? Or do we need to solve 100% of the issues? What is the opportunity cost of solving 100%?
Wireframes have been developed by UX with business unit and product team input
The experience is often been validated with customers
A better understanding of the technical effort and viability leading to better estimates