## Intro


#### Problem to be solved/ User story

> *Start this section with a succinct problem statement or user story that describes who this is for and what problem it helps them overcome. Some examples.*
> 
> 
> 
> *   *The device team wants to be able to test and release the OS for every supported device whenever a new meta-balena version is released.*
> *   *As a Fleet Owner, I would like to be able to search for a specific device across all of my applications.*
> *   *As a new balena employee, I would like to know what I should do in my first week on the job.*
> 
> *This user/problem statement can be as short or as long as needed, but should ultimately be a litmus test or way to check if the project is still on track and solving the problem it set out to solve. It’s important for the team working on the project to know who is ideal user and what that user is trying to accomplish. This section should also “sell” why this project is important. Listing who it impacts and by how much.*


#### Define your User/Customer/Consumer

> Be sure to figure out who you are building this for and make sure the team all has the same target user(s) in mind.


#### How is it currently solved?

> Next describe how the user “Solves this currently”, whether it is via a workaround, building it themselves or going to a competitive product.


#### The New Solution

> Here we will describe the solution. In this section try focus purely on the feature or process the user will follow and how they will interact with the new solution. This is the time to link to any rough wireframes, drawings or documentation. 
> 
> In theory this section could ultimately be turned into a blog post or press release on the new change. Is important **NOT** to go into technical implementation at this point.


## Implementation


#### Proposed Implementation (1 or multiple)

> This is where it gets technical. This section should describe how we actually go about making the new change to the system. We should detail the required model or process changes that need to take place and describe the added or changed interfaces that will be needed.


#### Migration Plan

> It should also take into account how we handle transitioning from what we currently have “in production” to the new solution and any dependencies or processes that need to be up and running before hand.


#### Release Plan

> Here we layout how this project is released to the world. Does it need a blog post, does it need docs. Who are the people that are interested in hearing about it and how do we let them know about it.


#### Resources Need

> Estimate of engineers needed and time.


#### Potential Issues/Risk/Blockers

> Detail things that could cause delay or unpredictability in the proposed implementation plan.


## Milestones

> The milestones should layout core pieces of work that need to be achieved, this will vary from project to project, but something like “Design wireframes” for a UI related spec is an obvious milestone. Milestones should be ordered and if possible try indicate where one milestone has dependencies on others.
> 
> Ideally it should be possible to group the milestones in to a set that achieves a Minimal Viable Product (MVP) and then additional nice to have or stretch milestones can be listed below.


## Links & References

> Add links to recorded video brainstorms or discussions