---
tags: library, Project Plan, process
---

# Project + Product Lifecyle v2

## Tl;dr

What was a [clear process doc](https://hackmd.io/@Govrn/SJ-Cm5Bnq/%2Fok5Jn9ThT_qYUwXaIg4GKg) and [a few](https://hackmd.io/@Govrn/SJ-Cm5Bnq/%2FUWisSR5bQaC_82NIffhu8A) software tools has now grown. Ideas now [have a map](https://www.figma.com/file/AxBK3MICEcDgpcpjn8ST2E/Idea-Lifecycle-v2?node-id=0%3A1&t=FbIEKf8FnlCzhPGR-1) and a [project plan process](https://hackmd.io/tp51AihXQgKsG7KacyOPAw?view) helping navigate said map.

### Summary

Enabling everyone for success is critical, we need a documented and flexible idea lifecyle. As a result of new team members we have additional resources to tackle ideas. It's up to the team to determine where we go in the map. This doc should summarize a demo flow for any idea that ends in a product feature.

:::info
This is a living doc 🛣 Your mileage may vary.
:::

Some projects will ship quickly and go straight to build, others may do a few cycles (6 weeks) in exploratory mode and user testing.

### Some counterintuitive things:

- we shouldn't be afraid to push a project back in to discovery or exploration; or break off into phases/iterations.
- we should strive to ask simple questions with our DAOs to get their thoughts, and combine that with our deep expertise.
- Ideas will loop a couple times, that's good!
- We may be able to vote, we may not. That's what pitch sessions and open project review day is for.
- Projects need time to percolate so there may be more than one call, not only a kickoff.
- As our product grows so too does the [dependency map](https://www.figma.com/file/SIahJ4DQuEX8WufaJ8dVBG/Product-gitflow?node-id=0%3A1&t=6dJbnecQCidRks5B-1) and complexity. we will try to keep this up to date.
- ***Not everything has to fit into a label or bucket.*** We can have fun with this process.


💡 At a high level we have many ideas, we should document and start as many as possible but balance that against saying no earlier. This map is the phases and the loop of idea generation.


#### The simplest framing for all projects: "it's one hackmd that grows."

📒 From a one pager/project plan + a linear project => into a project plan with kickoff=> until there's a design file or a few=> a vote session=> everything is then scheduled for build. Along the Govrn journey we'll add more resourcing ***upfront***, **with our users** helping prioritize and answer questions plus unblocking dependencies.


🌺 More concrete outcomes within each phase (in blue) and escape hatches for complexity, bandwith, or blockers.


🗳 If you like flow charts, here is what it looks like to vote on a project twice and how it could continue or not. Plus, some questions to ask ourselves.


👆 A swimlanes demo: here is what consulting teammates and two paths of a research project might look like. Note that stoneface (voting) could fit in early or later with more definition. Or possibly that a project needs a few calls. Or it fins wrapping up at 6 weeks with new relevant projects and version names is better. Your mileage may and will vary.

---

::: spoiler #### Changelog
- updated the [project plan process](https://hackmd.io/tp51AihXQgKsG7KacyOPAw?view) with relevant linking
- updated the [v1 lifecycle](https://hackmd.io/@Govrn/SJ-Cm5Bnq/%2Fok5Jn9ThT_qYUwXaIg4GKg) to one pager process and cross linked
- updated the project plan template
- Added tags
- Pushed this to library
-
:::