Guide: Web Property Lifecycle Best Practices

Full best practices

JTBD/user story

• ⏰To avoid premature solutioning, start the needs assessment process with a simple product definition stated as a problem/benefit sequence (e.g. user story or Job To Be Done)

Outcomes

• ⏰What existing, executive-approved, high-level outcome is this work attached to?
• Is that outcome high enough on your org's current list of priorities to justify the work?
• Is the project directly enough attached to the high-level outcome? Can it be easily proven to move a needle or improve metrics for a current top goal?

Customers

• ⏰Who are the stakeholders?
• Internal (possibly prioritizing for high-value parties based on current org goals)
• External (possibly prioritizing for high-value parties based on current org goals)
• ⏰If the users are different from the stakeholders, are they high-value enough to your org to justify this project right now?
• ⏰Are they someone else's users/stakeholders too — could you underwrite someone in the wider open-source community to do this work instead?
• ☝️Do you know enough about them to be able to serve them well?
• If not, are you prepared as part of this project to do the research necessary?

Costs/benefits

• ⏰Can an existing web property template (or a significant number of individual UI components) somewhere within the org be used to lessen time/labor cost?
• If not, does this project add value as the first example of a new template?
• ⏰Can this product justify its maintenance burden?
• What's the expected and what's the bare-minimum cadence/frequency for updates and/or enhancements?
• Do you have a DRI (directly responsible individual) available for that amount of work going forward?
• Are you realistically prepared to promise minimum support until EOL, even considering any possible org re-prioritizations?
• ☝️What's the differential between bare-minimum and preferred solution (in feature set, time, cost)? Are you prepared to accept bare minimum if we need to?
• ☝️Can the benefits of this project be expressed quantitatively or qualitatively?
• If qualitatively, is it worth proceeding to spec phase knowing this project may be harder to justify?

Full best practices

High-level goals and risks

• Considering the outcome, what proxies are you going to use to measure success?
• ⏰Define immediate success (to be used as initial "definition of done")
• ☝️Define longer-term success (to be used as future key performance indicators)
• Define metrics first, so all specifications can be driven from them
• ⏰If a feature can't directly contribute to improving metrics, it should be discarded from scope
• Define possible risks to project, including severity of impact and whether they are acceptable/can be mitigated:
• ⏰Possible show-stoppers (both technical and otherwise)
• ☝️Possible timeline blowouts
• 💎Possible tech debt

Timeline and lifespan

• Define rough timeline
• ⏰Bare-minimum solution timeline
• ☝️Preferred solution timeline
• ☝️Use the differential between the two to help determine initial scope, particularly relative to anticipated budget
• 💎If no hard deadline or budget cap, consider other factors that might determine timeline and/or scope (e.g. time until any known staffing changes, pressure to get the project out as a template for future work, etc)
• Define project lifespan: fixed, eternal?
• ⏰If fixed lifespan, define either sunset date or check-in date for determining sunset date
• ☝️If eternal lifespan, define process and standards for periodic value assessment

Architecture

• ⏰Which template sites and/or existing UI components can be used to speed time-to-launch?
• How much customization (visual, functional) will be needed?
• How will content be added to the site (markdown-driven, JSON-driven, database-driven)?
• Is there an existing pipeline for that content flow, or is that net-new work?
• Do low-code content solutions (e.g. Forestry) need to be included (see below)?
• ⏰What APIs will need to be used?
• Does tooling already exist for this?
• ⏰Which org-wide processes/platforms need including?
• CI/CD pipelines
• Analytics (including whether existing dashboards can be cloned)
• Speed-testing or similar performance instrumentation
• Internationalization (including whether i18n must be complete at launch, or if community contribution later is OK)
• Do vendor agreements with any of the above need upgrading to accommodate extra traffic etc?

Resourcing

• ⏰Can the project build as a whole be outsourced?
• If not, business justification may be more difficult and may still need to budget for in-house project management and infra/launch support
• ☝️How much user research needs to be done in order to confidently ship? Will you do dedicated user research first, or use a build-test-build methodology?
• If dedicated research phase, time-budget/assign DRIs and adjust timeline accordingly
• If build-test-build, understand the impact this could have on project velocity overall
• ⏰Can existing org staff adequately support initial launch (infra, comms, marketing, social)?
• ⏰Can ongoing maintenance be adequately supported internally/externally until sunset date (or indefinitely)?
• Maintenance includes code, content, metrics monitoring, social/marketing/community
• Define SLA for maintainer response
• How much technical expertise can be reasonably expected of content/social/marketing maintainers? Does spec need to expand in order to enable low-code contribution or maintenance?

Administrative/PM

• ☝️Define launch plan (infra, comms, marketing, social) and time-budget/assign DRIs
• ☝️Create rough financial budget for procurement consideration and contractor level-setting
• ☝️Capture goals, timeline, architecture from above as formal PRD (product requirements document), to be used for:
• Internal business justification and/or procurement
• Brief to give potential contractors for issuing bids
• Generating issues/epics/acceptance criteria in build phase

Full best practices

PM setup

• ⏰Ensure MVP/shipping-first mindset with clearly defined, deliverable milestones along the way that demonstrate value to stakeholders/users
• ☝️If user research/testing is to happen in build-test-build style, now is the time to plan for doing this in a way that minimizes the impact on project velocity overall
• Realize this may introduce a dependency on the availability of user testing partners
• ☝️Assign DRI for project management and progress reporting
• 💎Convert PRD DoDs (definitions of done) into issues, epics, acceptance criteria, etc, so executives can drop in at any time and understand progress

Architecture

• ⏰Define/approve any data models necessary, using existing patterns whenever possible
• ⏰Separate and assign work based on net-new code vs customization of existing components
• ☝️Define any CI/CD, linting, other repo-level actions and set up as early as possible to avoid time crunches later

Administrative & reporting

• ⏰Generate metrics dashboards and other reporting as you build and include as a launch requirement, not post-launch add-on
• ⏰Install any other reporting (speed, accessibility, etc) as you build
• ☝️Set up internationalization workflow as you build
• Do you have existing i18n patterns or resources elsewhere to duplicate, or does this need to be set up net-new?
• Is it necessary to fully localize prior to launch, or can translations etc happen via community contributions later?
• 💎Install, set up, and confirm functionality of any maintainer alerts (e.g. metrics slippage, new content requests, community PRs, etc)

Tech debt

• ⏰Define, issue-ize, and backlog tech debt as it accumulates in order to keep a running total of post-launch responsibilities
• ☝️Determine what can safely be rolled into maintenance phase and what must be included in DoD

Full best practices

User testing

• Determine test methodology, balanced against effort required (examples)
• ☝️Qualitative vs quantitative methodology, moderated vs unmoderated, user testing vs concept testing, etc
• Recruit participants
• ⏰Do international privacy (GDPR, etc) regulations need to be considered?
• ☝️Will extra time be needed to do synchronous testing (over Zoom, etc)?
• 💎Any extra time/effort for paperwork: buying/sending gift cards, securing NDAs, etc?
• Create test artifacts as "minimum believable product"
• ☝️Which provides better agility and overall delivery velocity: test artifacts built with a design tool (e.g. Figma), or test artifacts built in basic code that can be used in build later?
• Do the tests
• ☝️Synthesize the test results
• ☝️Generate next-steps recommendations
• 💎Turn those recommendations into discrete issues that devs can implement
• Additional considerations for build-test-build situations:
• ☝️Define thresholds for when poor user test results can require product realignment/pause
• 💎Determine cadence and plan overall dev work accordingly to avoid harming velocity

Functional testing

• ⏰Unit and integration testing
• ☝️Speed testing
• ☝️Accessibility testing

Continuity testing

• ⏰Repair broken inbound links over which your org has control (e.g. in your other web properties, GitHub repos, etc)
• ☝️Add redirects for important broken inbound links out of your control (may need immediate post-launch attention after monitoring 404 logs)
• 💎Ensure other forms of social continuity aren't disrupted (e.g. RSS feeds, forum-posting bots, embedded content in other locations, etc)

Full best practices

Immediate post-launch

• ⏰Remember that initial maintenance/bugfix and enhancement responsibilities are likely to spike soon after launch as bugs and initial live user feedback emerge

Ongoing maintenance

• ⏰If project lifespan still TBD, set deadline and DRI for making that decision
• ⏰If project lifespan is evergreen, commit to periodically assessing whether the maintenance burden is worth the benefit, and consider all forms of maintenance: code, content, monitoring, metrics action, social/marketing

Enhancements

• ☝️For enhancements, follow this best-practices guide again to the degree that it's practical

Full best practices

Scoping

• What user/stakeholder comms are needed to avoid disruption? Plan accordingly, both in terms of timeline and of required effort by internal/external resources. Examples may include:
• ☝️"This project is deprecated" landing page
• ☝️Inbound link fixes
• 💎Social/email/forum messaging before, during, after sunset (including monitoring for x weeks/months after the fact)
• Is another product replacing this one?
• ☝️If so, is it equipped to meet user/stakeholder needs, or does additional work need to be done on the replacement?
• Is EOL-ing anything in this project going to impact any internal or external/community dependencies ...
• ⏰To a degree of existential harm, or for a high-value item?
• 💎To a degree of inconvenience?
• Can any infra services be decommissioned/scaled down as a result?
• ⏰Will this happen automatically, or does anything need to be actioned?

Post-sunset cleanup

• ⏰Archive repos so no one accidentally opens issues, makes fixes, etc
• ⏰Make sure any permissions no longer needed are revoked
• ☝️Repair broken inbound links over which you have control (e.g. in your other web properties, GitHub repos, etc)
• 💎Add redirects for important broken inbound links out of your control (may need immediate post-launch attention after monitoring 404 logs)