# ♻ Status Feature Flow Exploratory Calls
## 🎨 Design Team
- Multiple platform directions are not helpful
- Features across platforms should be considered and worked on as close to simultaneously as possible
- Reduces efficiency of work to drop and re-pick up context with months apart
- Having multiple CCs involved from an early stage has positive impact for marketing so that comms can be clearer
- 3 Amigos may need to be flexible on the "3" part

## 📄 Docs Team
- Concern about starting with a feature with a figma file
	- It is uncertain what is implemented and what is not
- Developers write on github, doc team have to hunt down the epics or issues
	- Also it is uncertain what will be included in what release
- Is there shared workspace for all of the activity that the CCs work on
	- Consider Crews workspace template
- Formalise the process of share a screenshot of the feature in the documentation, and release articles
- Changes to features need to be documented somewhere
	- Record somehow that a change decision was made.
	-  Explore automation process to highlight when feature changes are made
- When writing an article about a new feature identify who the developers are
- Automate alerting teams when certain stages of a feature lifecycle have been met.
	- Possibly link into label inclusion for same with QA

## 🖥️🔍 Desktop QA
- The development process doesn't include user stories during a particular point
- Issues lack an entry point in the development lifecycle
- We should have some kind of business ownership of building processes
- Revenue needs to have specific goals from a particular role
- We should have processes that allow us to compete with small startup team in the web3 space.
- Sometimes a user story may be too formal and scary to interact with. It is too much / overkill
- Ideation output needs to be easy to access for anyone, less formal than user stories
- Experts should give input at the appropriate place.
	- Different stages don't require everyone's input, but they should have visibility
- Who should be responsible for quality?
- Potential to move the QA bottleneck from the PR stage to the Acceptance Requirements stage.
- Requests for PR review on demand seriously damages the ability to plan work
	- No visibility of what is up coming from the development team
- Currently QA time is not considered as part of the timeline.
	- QA work is assumed to be doable within a day's work.
- Testing needs to be integrated into the whole workflow including in time estimations.
- We need to remedy the friction between using Github vs Notion for integrating user stories into the development process
- Reconciling the different styles of development between all teams.
- We need to decide and account for divergence in feature parity across platforms
	- Some platforms are unsuitable for certain features
	- But that decision needs to be made and recorded.
- We should have a pool of feature ideas that can be fed from multiple sources, but it is prioritised and organised.
	- Inputs from:
		- user feedback
		- CC ideas
		- Business considerations
- B2B relationships are a fertile ground for discovering feature improvements

## 🖥️👛 Desktop Wallet
- We need context on the document
- Do we need every stage of a process some things need to be flexibility.
- Flows need to be simple
- Feedback stages need to have an output that feeds into ideation (or roadmap), to ensure a proper cycle
- Iterative development needs to be considered
- Input from other teams such as legal to give 
- At each stage the 3 Amigos should decide what should the next step should be and contain
	- cycling back may be an option

## 🖥️🤘 Desktop Core
- At least integration tests should be included in feature
- Functional tests should be required
- Having tests in mind allow you to have good code.
- Technical specs are needed.
- Feedback loops should be required throughout the stages
- Technical specs are hard to produce in a single step
	- But the specs shouldn't be done all at the end of the process
	- Specs should exist at the beginning but not in there entirity
- Technical specs could be living documents that update as the implementation progresses.
- Flexibility is very important
	- Declare that the proce 
- spikes should be considered
- Document decisions
- https://www.industrialempathy.com/posts/design-docs-at-google/
- Features should be welcomed by everybody
- Possibly retrospective specifications based on the code, to build 

## Volo
- Nominate a point of contact that drives the feature.
- Team lead should always know what is happening within a group.

## 📱👛 Mobile Wallet
- flexibility on flows should be considered
- some features do not require specific documents, flexibility is necessary
- Notion vs Github consideration
	- Move to github
	- we can have the ability to close issues of milestone / epic / user story types, which is not inherent in Notion.
- https://www.notion.so/Activity-Mobile-63d352b527844a48a296470340f5e445 A good feature to experiment with a new approach

## 📱🤘 Mobile Core
- Requirements are a gradually developing process
- Need the ability to loop back in the process when discovering 
- Epics may like require multiple 3 amigos
- How do you measure success? Compare against OKRs.
- Assess success criteria measured against the OKRs.
- Develop a process of gathering feature ideas from:
	- CCs
	- Users
	- Business
	- Leads
- Voting system on a Notion page
	- Anonymous
	- Start simple.
- What stage does research occur
- We need to implement an exit phase for features that should be ended - Parvesh
	- We need record rationale / decision making process