Projects

If a project is 🦁 large or 🐘 extra large, and multiple smaller projects are part of it, it’s called a programme.

Validate how you could break your programme down into a 🐛 small or 🐓 medium projects — otherwise it could be hard to break it into tasks.

*Could be cyclical e.g. pay review

*That’s a programme

Tasks

If a task is 🦁 large or 🐘 extra large, break it down into a 🐛 small or 🐓 medium task. It’ll be easier and clearer to action.

An MVP and a draft are not the same. What does it mean to build a v1 of something, and how do we know it’s an MVP?

☑️ A timeline

☑️ Alignment on how we approach performance (e.g. how often, how many indicators if any, etc.)

☑️ A Leapsome cycle

☑️ High level heads up about the why + how

☑️ A confluence page for managers about the process

☑️ A confluence page for managers about indicators

☑️ A confluence page for employees about the process

➕ A confluence page with roleplay examples

➕ A training session for managers

➕ A training session for employees

➕ A training session for new joiners

➕ A presentation (recorded) about why + how

➕ A toolkit

➕ Refresher training sessions

Screenshot 2023-07-26 at 16.33.38.png

<aside> 💡 Note — Every MVP is still a good product in itself, at a quality level that will serve the user.

</aside>

If our goal here was to go across town, and we were building a product…

Minimum Viable Products should still…

[ ] Our colours and branding
[ ] Bullet points vs prose, to make the content easy to digest and skim-read
[ ] Content that’s short & to the point — it’s about what you can land!
[ ] Columns or split slides - to see more at a glance!
[ ] Humanised language - ‘policy’ → ‘guidance’ so it’s easy to understand. Ask yourself: Would you say it out loud?
[ ] Start with why does your product, process or update matter?
[ ] Be scalable — we're building products that help us work better today, but if we think at scale it can also help us tomorrow

<aside> 💡 Tip — Ask yourself…