The product vision should demonstrate how the product would deliver value to it’s users. The strategy is the game plan to fulfill the vision and discovery defines what is known (or unknown) as well as any constraints that exist. We spend an entire phase of the project working on discovery and strategy with our clients.
We like to focus on crucial user journey tasks first. Then we prioritize all other features with the lowest effort and highest business value. When you’re done, your backlog should look clean, estimated, and organized. Your project manager plans the work into logical sprints of time and helps prepare for future releases.
Prototyping upfront always reduces the time and money spent down the line. We create customer journey maps, personas and user flows to inform our team about the needs of your customers. This knowledge then gets put into a designed prototype that you can try out. This is the time to test the design and experience.
Our design team spends a great deal of time understanding your brand and purpose. They use that research to provide art direction, mood boards, style guides, iconography, and final product designs. All of our designs are created with the goal of satisfying the end-user.
The agile methodology provides a structure for team communication, task-based estimating and reporting that tracks a team’s ability to get work done. Our development team is training in the 70/30 rule to deliver the highest quality experience possible.
Our project managers provide excellent service as well as tactics to plan for quality. They keep teams aligned and can navigate changes in the product. Our process and expertise increases quality, predicts completion dates, and keeps the budget on track.
We collaborate with our clients using an established framework to define a phase one. The product backlog tracks future phases, but we focus on the highest priority items first with a plan to ship early and often.
Most of the time is spent in the development phase of a project. We keep backlogs groomed, plan our sprints, provide in-sprint QA, and harden the product. The goal is simple, deliver quality, collaborate, and plan for the future.
Your backlog should only include actionable tickets. All of the user stories are defined and estimated. Each user story sorted in the order of priority. We use sprint planning to help with planning the roadmap and figuring out future phases.
When working with a large group of people on a new product, often, every feature becomes a priority. And if all elements are a priority, then there is no priority. Our team is trained to work with clients and their needs to identify the absolute must-haves to determine the first phase of a product. The process involves evaluating the business value and effort of each item and tie estimates back to the budget. In every digital project we have ever launched, there have been multiple phases, it’s good to accept that up front. In our experience, things can change so much and so fast that it’s generally to get a more focused product released earlier and iterate on it’s features over time.
Lots and lots of discipline. It’s not easy to predict the future, and it’s tough to do with a moving target, so the best way to attempt being a fortune teller is to remove as many variables as possible. In our experience, we found that waiting to test products at the end of the development phases led to long Alpha and Beta periods. Waiting until the end of development to start testing is not ideal, there should NEVER be unexpected delays at the end of a project. Delays should be known well before going into a testing period. Also, avoid adding new features without removing features. When new ideas get added to the product, old ideas should be challenged and re-prioritized. If 3 points of work get added, then 3 points of work should be removed. There are always multiple phases to a project, and not everything needs to be done at once.
The key to launching a product with few surprises is to avoid technology black holes, that’s the period developers are working without reviewing the application with a customer. Focusing on QA in each agile sprint and only allowing 70% of the sprint dedicated to featuring development has many advantages. We’ve written extensively about the benefits of the 70/30 rule, and it really works. Waiting to test everything at the end of a project usually leads to a massive amount of bugs created and a team that is now working as hard and fast as they can to hit their launch date. Don’t fall into that trap! Our team has launched products early using this method.
No problem. Change is inevitable, and priorities change. If a scope change takes place, the question becomes, how many story points (work estimate) is the change worth? Are any other stories no longer relevant? Can we make a trade? Adding more points without adjusting time or budget doesn’t always work unless the project is currently under budget (it does happen). The beauty of negotiating story points is that features are pulled out to keep the project on track and marked for a future phase of the product. The backlog should ALWAYS support reality. Any tickets that are outdated or obsolete are updated or deleted.
Our teams break down big ideas into their simplest form. They work with you all the way from ideation through delivery and support you every step of the way.