Overview & Philosophy
Agapic’s product mission is to consistently create products and experiences that further our mission & purpose and align with our values.
But Wait, Isn’t This A Waterfall?
No. Although the phases described on this page appear to be independent and linear, they are not. They’re presented in this way for simplicity and ease of navigation. At Agapic, we do not promote working in a linear manner. Phases in the product development lifecycle may overlap or occur in parallel.
We aim to achieve key outcomes in each phase in order to de-risk subsequent phases. However, this page doesn’t dictate the order we go through the phases, or the time spent in each. When we have a high confidence in our direction, we should feel empowered to skip or shorten phases that won’t contribute to improved confidence.
Workflow Summary
Validation Track: Test Our Vision
- Validation Backlog: Collect Ideas
- Validation in Progress: Understand the Problem, Prototype It, and Test with Users
Build Track: Build Our Vision
- Build Planning: Break Down the Work
- Building & Testing: Build and Test It
- Launched to Users: Shipped Improvements
Issue descriptions as the Single Source of Truth (SSOT)
Issue descriptions shall always be maintained as the SSOT. It’s not efficient for contributors to need to read every comment in an issue to understand the current state.
- Issue description accuracy should be maintained by the directly responsible individual (DRI) throughout each phase. However, all collaborators can and should contribute when they see discrepancies or needed updates.
Validation track
For new ideas where the member problem and solution isn’t well understood, we should work to validate new opportunities before moving to the Build track. The Validation track should get ahead of the Build track, so that the Build track always has well-validated product opportunities ready to start. Validation cycles may not be necessary for things like bug fixes, well understood iterative improvements, minor design fixes, and technical debt.
The goal of the Validation track is to give us confidence that a proposed solution will positively impact Agapic’s mission & purpose and align with our values. If we don’t have confidence in the Minimal Viable Change (MVC) or what success looks like, we should continue validation cycles before we move to the Build track.
Validation phase 1: Validation backlog
Description
Refine our backlog to ensure validation opportunities are scoped and prioritized in line with product direction. An issue position in the backlog, along with the description, discussion, and metadata on those issues are key pieces of data necessary to keep team members up to date on the validation track.
| Outcomes | Activities |
|---|---|
| Up to date issues: At Agapic, issues are the SSOT for any change to the product. Keeping these up to date increases efficiency and transparency by allowing all team members to understand the planned work. | - Create issues for new features. - Review issue discussions and update relevant info in the description. - Keep metadata (such as labels) up-to-date. - Actively respond to stakeholder comments. - Transfer discussion notes, and external information to the issue (as links or discussion/description details). |
| Prioritized backlog: The issue backlog is the primary signal stakeholders use to know what’s “up next” for the product. The backlog is also the queue for the team to work from, as features progress through the Product Development Flow phases. This queue is kept up to date on project boards. | - Regular review of issue prioritization (such as issue board ordering). - Align prioritized backlog to product direction. |
Validation phase 2: Validation in progress
Problem validation
To ensure the right solutions are delivered, the team must start their work with a validated problem, which is a well understood and clearly articulated member problem.
Examples of small and well-understood problems that can be quickly validated include user requested issues. If the problem is nuanced or not yet well understood, then it will take longer to validate with users.
This phase’s primary outcome is a clear understanding of the problem, along with a simple and clear way to communicate the problem to various stakeholders.
| Outcomes | Activities |
|---|---|
| Thorough understanding of the problem: The team understands the problem, who it affects, when and why, and how solving the problem maps to business needs and product strategy. | - Execute a research study (contextual inquiry, in-depth interviews with potential users or stakeholders, review published research, etc.). - Understand who experiences the problem, and how the problem varies by population segments, including by disease or by specialty. - Validate your problem with users and document your findings. |
| Update issue description: A well understood and clearly articulated member problem is added to the issue. This will help with successful and efficient design and development. | - Ensure your issue is up-to-date with the latest understanding of the problem. - Understand and document (in the issue) the goals that people want to accomplish. - Communicate the problem to all stakeholders. |
| Initiate the dogfooding process: When validating problems, it’s important to gather feedback from internal members, in addition to the broader community. Capturing internal member feedback early on in the product development flow helps ensure their needs are considered as the feature matures. | - Capture internal member feedback to help inform initial and/or future iterations of a feature. |
Design
Ideate potential solutions, including incremental modifications to existing solutions (if any), and explore different approaches before converging on a single solution. Evaluate solutions by determining if they meet member and business goals, and are technically feasible. Engage with stakeholders to determine potential flaws, missed use cases, potential security risks, and if the solution has the intended member impact. Converge on the proposed solution or identify a small set of options to validate.
| Outcomes | Activities |
|---|---|
| Proposed solution(s) identified and documented: Explore solutions and identify the approach(es) that strike the best balance of user experience, member value, business value, and development cost. | Diverge: explore multiple different approaches as a team. Example activities: - Think big sessions: focus on divergent thinking about a problem and the solution space. - Creating user flows or journey maps. Converge: identify a small set of options to validate. Example activities: - Think small sessions: define the smallest step that the team can take today. - Design reviews with team. - Low fidelity design ideas. - Update issue description with proposed solution. Add design file link to communicate the solution idea. - Validate approach with help from stakeholders. Run user validation and document your findings in the GitHub issue. - Draw inspiration from competitive and adjacent offerings. Key questions: - Why will the proposed solution make a patient’s life easier? - Why will the proposed solution make a physician’s life easier? - Who will be excited by the solution, and does the solution’s value to the user vary by population segment (by disease, speciality, etc.)? - Does the solution align with Agapic’s values? |
| Shared understanding in the team of the proposed solution: Lead the broader team through a review of the proposed solution(s). | - Review the proposed solution as a team so that everyone has a chance to contribute, ask questions, raise concerns, and suggest alternatives. |
| Confidence in the technical feasibility: It’s important that Engineering understands the technical feasibility of the solution(s) to avoid rework or significant changes when we start the build phase. | - Discuss the technical implications with Engineering to ensure that what is being proposed is possible within the desired timeframe. - Engage engineering peers early and often through Slack messages, pins on issues, or by scheduling sessions to discuss the proposal. |
| Updated issue description: Ensure issues are up-to-date. | - Ensure issues are up-to-date, so we can continue our work efficiently and asynchronously. |
| Continue dogfooding process | - If applicable to the feature, continue the dogfooding process. |
Solution Validation
After identifying one or more potential solutions that meet business requirements and are technically feasible, ensure that we have confidence that the proposed solution will meet the user’s needs and expectations. This confidence can be obtained from work performed during product design and supplemented with additional research (including user interviews, usability testing, or solution validation).
| Outcomes | Activities |
|---|---|
| High confidence in the proposed solution: Confidence that the jobs to be done outlined within the problem statement can be fulfilled by the proposed solution. | - Gather feedback from relevant stakeholders. |
| Documented solution validation learnings: The results of the solution validation is communicated to and understood by team members. | - Document solution validation findings. - Update issue description to contain or link to the findings. |
Build track
The build track is where we plan, develop, and deliver value to our users by building MVCs, fixing defects, patching security vulnerabilities, enhancing user experience, and improving performance. Engineers work closely together to implement MVCs, while remaining in close collaboration with other stakeholders. Decisions are made quickly if challenges arise. We instrument usage and track product performance, so after MVCs are delivered to members, feedback is captured quickly for learnings to refine the next iteration.
The goal of the Build track is to deliver performant MVCs that improve Agapic’s performance. If it fails to do so, honor our efficiency value, abandon it, and restart the validation cycle to identify the right solution.
Build phase 1: Build Planning
Description
This phase prepares features so they are ready to be built by engineering. Bugs, technical debt, and other similar changes that are not features may enter the process in this phase. Following Validation Phase 2 the feature should already be broken down into the quickest change possible to improve the user’s outcome and be ready for a more detailed review by engineering. Tradeoff decisions can be made and feature issues evolve from validated solutions to clear MVCs that can be delivered in a single week. Be sure to document all decisions on issues.
Outcomes and Activities
| Outcomes | Activities |
|---|---|
| Well-scoped MVC issues - Issues are the SSOT for all feature development. | - Refine issues into something that can be delivered within a couple days. - Prioritize the issue relative to other issues. - Review feature issues with contributors - Make scope tradeoffs to reach for a right-sized MVC that delivers the smallest possible solution that offers value to our users. - Request an issue review to ensure communication is clear and that the issue proposes the right iteration plan to execute on the solution. |
| Prioritized issues - The team should understand what issues should be delivered during the next week. | - Make clear which issues are ready for development and are prioritized for the next week - Engineering signals acceptance of the issue in the next week |
Build phase 2: Building & Testing
Description
The building and testing phase is where we build the features, address bugs or technical debt and test the solutions before launching them. The DRI is responsible for prioritizing what should be worked on; however, the software engineers are responsible for the implementation of the feature. Documentation for the work will be developed by the engineer. Many team members are likely to contribute to a single issue and collaboration is key.
Outcomes and Activities
| Outcomes | Activities |
|---|---|
| Feature is built | - Engineering checks that the definition of done is met - Provide regular status updates to stakeholders - Provide asynchronous updates to avoid status check-ins and synchronous stand-ups |
| Feature is tested | - Engineers test features they implement. - Engineers complete a review of any developed documentation. |
Build phase 3: Launched to Users
Description
When the change becomes available in production, the issue is closed by the development team so stakeholders know work on it has been completed. Afterward, coordinate the release post and dogfooding process when they apply.
Outcomes and Activities
| Outcomes | Activities |
|---|---|
| Feature is available to Agapic members: After it’s deployed to production, the feature is launched and available to Agapic members. | - Code is deployed to production. |
| Stakeholders of a feature will know it’s available in production | - After the feature is deployed to production and any needed verification in production is completed, the development team will close the issue. - The DRI may follow up with individual stakeholders to let them know the feature is available. |
| Members will be informed about major changes: When appropriate for a change, a release post will be written and shared by the DRI. | - Release post made and shared with members. |
| Continue dogfooding process | - If the DRI wants to dogfood the feature and it’s ready for internal consumption, the DRI promotes it internally. |
Improve
After launch, the DRI should pay close attention to product usage data. This starts by ensuring your feature is instrumented and reporting as you expect. Consider how the feature has impacted DAU and MAU. At this point you should also solicit member feedback to guide follow-on iterative improvements, until success metrics are achieved/exceeded and a decision can be made that the product experience is sufficient.
Outcomes and Activities
| Outcomes | Activities |
|---|---|
| Understand qualitative feedback: To know how to improve something, it’s important to understand the qualitative feedback that we’re hearing from members and team members. | - Continue dogfooding process. - Review user feedback. - Follow up on feedback from interested members. - Set up follow-up calls with members to gather more specific feedback. - Consider running a survey for usability. |
| Measure quantitative impact: Qualitative data is great, but coupling it with quantitative data can help to paint the full picture of what is going on. Set up dashboards and review the performance and engagement of your change. | - Set up or update any applicable dashboards and reporting. - Understand if the new feature or improvement has impacted core metrics, such as DAU or MAU. |
| Take action on learnings: After you understand the qualitative and quantitative impact, you can take action on your learnings by creating new issues or updating existing open issues with more information. | - Open new issues or revise existing open issues for follow-on iterations and improvements. - Ensure you’ve captured feedback in issues. - Share learnings with stakeholders. - Consider sharing learnings with the broader team. - Update follow-up issues with results and specific next steps. |