New features and requirements

This document describes how the business, product, development, marketing, and QA teams can interact on the new feature development lifecycle. This process must be used for any major features. In some cases for simpler features, simplified versions of this process may be warranted. If you're not sure, discuss how to proceed on a new feature with Michael S.

Roadmap planning

Defining a roadmap gives us guidelines for the features we'll be rolling out over a significant period of time, usually 6-12 months. By identifying a set of changes on a roadmap, we can ensure we properly plan engineering to delivery on the needs of business and marketing. The goal of roadmap planning should be:

  • Get as many features discovered as possible that may be desired in the future
  • Have a clear delivery plan with lots of milestones, including a clearly defined MVP
  • Engineer the solution to allow for future growth, especially future features

To reach these goals, we should follow a process like this:

  • Brainstorming Come up with a list of features we may want to include
    • Brainstorming can be asynchronous and last for weeks
    • Dedicated brainstorming video calls can be very effective
    • Track the ideas centrally. Google Drive docs work well for this
  • Prune Do a first pass of the ideas as a team and eliminate features we definitely don't want to do
  • Quantify Assign some point value for each feature for each of the following:
    • Business value: how much will this help the company?
    • Engineering cost
    • Other factors that would impact scheduling (such as hard external deadlines)
  • Organize Sort the features and group them into logical milestones
    • We want to focus on getting coherent deliverables! Shipping is a feature too.
    • Prioritize based on a combination of business and engineering needs.
  • Schedule Create Jira work items and assign to sprints for implementation
    • Engineering may decide to do some work out-of-order to reduce costs.
    • For work items in the future, consider the possibility that priorities may shift and consider whether work item creation should be delayed.

An example of the last point from the development of the governance/vesting frontend:

Adding a tally of "how much vested LVN has this user claimed" to the smart contract is relatively speaking a small task. Adding that as indexer work is significantly harder and riskier. Doing a migration to add this data to the contract later is a major amount of work. By identifying this feature earlier, we can do the smart contract work now, even if we decide to hold off on the frontend work.

New feature requests

The process above works for planning out the entirety of the roadmap, but does not provide enough details for implementation of individual features. For individual features, we use the following process for getting workable requirements:

  • The business and product managers (Jonathan and Don) have full responsibility for defining requirements
  • To improve our delivery time, requirements should always start at high-level business requirements, not product requirements or fully-fledged designs.
  • All stakeholders (Jonathan, Don, and Michael S) need to review and sign off on these high-level requirements before moving ahead with other steps.
  • Once a high level set of business requirements is defined, we can proceed with product requirements. These are not Figma designs.
  • Once all stakeholders sign off on this, we can proceed with Figma designs and get sign-off on these.
  • At that point, we can begin engineering work: functional requirements, architecture, development, etc.
graph TD
  clearBusinessNeed(Is the business need for this clear?)-->|Yes|stateBusinessRequirements(State the business requirements)
  clearBusinessNeed-->|No|stateBusinessNeed(Document why this feature helps the business)
  stateBusinessNeed-->stateBusinessRequirements
  stateBusinessRequirements-->reviewReqs(Get initial review from stakeholders - engineering, finance, UI design)
  reviewReqs-->|Feedback provided|incorporateFeedback(Incorporate feedback)
  incorporateFeedback-->stateBusinessRequirements
  reviewReqs-->|Receive signoff from stakeholders|createUiReqs
  createUiReqs(Create UI requirements)-->reviewUiReqs(Review UI requirements)
  reviewUiReqs-->|Modify functional requirements|functionalRequirements
  reviewUiReqs-->|Incorporate feedback|createUiReqs
  reviewUiReqs-->|Signoff|functionalRequirements
  functionalRequirements(Create functional requirements)-->reviewFuncReqs(Review functional requirements)
  reviewFuncReqs-->|Modify business requirements|stateBusinessRequirements
  reviewFuncReqs-->|Incorporate feedback|functionalRequirements
  reviewFuncReqs-->|Signoff|scheduleInJira(Create Jira work items and schedule work)

This is an exaggerated process for the most complex cases we would encounter in requirements. In many cases, some of these steps can be skipped entirely. But the important point is to delineate the process as going through the following logical steps:

  • Business requirements. This is very high level, such as "allow users to earn LVN rewards on LP deposits."
  • Functional requirements. This describes a specific implementation of the business requirements, such as "provide a smart contract that allows farming of xLP and automatically distributes LVN." Functional requirements will usually be very detailed technical documents.
  • Review the functional requirements and consider changes to the business requirements.
  • UI requirements. Only once we understand how the system should work, and know that it will address the business needs, should we move ahead with designing a UI.
  • UI requirements may demonstrate flaws in the functional requirements, which may even demonstrate changes needed in the business requirements. These should be addressed.
  • Once we have the business needs defined, know the overall technical implementation we want to take, and have the overall design, then can we plan on starting work.
  • Even at this point, it's very likely that mistakes in the functional requirements or UI requirements will be discovered during implementation, and decisions will need to be made to update these.

For very simple features like "change the link text to say X" or "adjust target utilization ratio in market Y," this longer process is not necessary. For many technical work items, we are simply optimizing or otherwise tweaking existing code which implements well-defined requirements.

In other words, the point of this isn't to be pedantic or bureaucratic. The point is to define a most-complex-case approach to how we approach this work.

Demo video scripts

One of the methods we've found for discovering requirements is to describe theoretical demo videos. These videos don't necessarily have to be made. The point is to walk through the process of thinking, "If I wanted to demonstrate the value of this feature to the outside world, how would I do it?" This has historically demonstrated gaps in the product and engineering requirements. Including this as part of brainstorming, business requirements, and product requirements is strongly recommended.

Another alternative to a video script could be tutorial text: write up how a user would perform relevant actions.