What is the problem
Let's take a step back on the goal we are working towards and what needs to be achieved.
We want motivation and quality output presumably throughout the year. It'll be a safe assumption if I say that motivation does contribute to quality work.
Now let's understand what are steps through development cycle which could impact these goals.
At a very high level
Product /feature ideation>Sorting of these ideas> selection of final list> validation through a framework> user validation> MVP experimentation> impact validation > finally the feature is shipped
Now what could go wrong? a lot, so lets identify the key problems
> I don't know WHAT I'm working on #planning
> I don't know WHY I'm working on it #GoalClarity
> I don't know WHAT my impact has been #Impact #Outcome
> I keep getting shifted from one project to another #ContextSwitching
> the feature I worked on didn't work out #Failure
> I keep getting the same work #Boredom
> The current work doesn't excite me #NeedtoLearn
From a PMing perspective : This is an end to end process. We can't solve them in isolation.
All the above problem can be solved through an agile approach combined with a thorough planning and communication rigour.
Collaborative Planning > Feature list/experiment list> planning > Execution> Experiment results > Feature roll out/ Learnings
This becomes an input to everything we achieve - it is ensuring we have well defined quarterly /six monthly planning process to ensure clarity on goals and timelines.
the outcome is a list of feature/product items we want to ship in order of their priority.
Once this planning is complete it is important to bring the tech stake holders into a room and get feedback from 2 key prespectives
-> Do they agree with the roadmap - does anything need to be removed/added
-> What can be picked
-> From a pure tech perspective - What needs to be added for planning
Example - upgrading the fresco library has no direct baring on the customer but from a tech stand point may be a task simply because it's more stable and solves some annoying but not so critical crashes?
> Now the tech stakeholders know the WHYs and WHAT they are working towards and what the impact is going to be
> it brings a fresh perspective to the ideas being discussed and ensure we don't have blindspots
Now that we have clarity on what needs to be done we figure who does what.
We want to ensure
- Everyone has work but isn't overloaded
- We leverage existing strength
- We allow people to learn/improve on certain areas
- Everyone knows what they are going to be working on
> Clarity in terms what I'll be working on and when
> Time for feedback - e.g if a frontend dev wants to brush up his server side skills maybe he'll call out that he wants to contribute server side on a project
During Execution it is important to ensure we build MVP of ideas for 2 reasons
- Derisking - Ensure we have validation before we invest
- Speed - this way we only invest on feature once we have early validation
The indirect outcome is
> you ship more winning ideas simply because due to the MVP scope you are able to experiment a lot more ideas and shipping winning feature is directly related to how many ideas you can ship /test
> Variety because you're trying out new ideas
> you win more often
> less likely to have boredom since you're constantly innovatin
This is where we really to work on communicating
-> Wins when we win
-> Learnings when we don't win, it's important to ensure we don't repeat mistakes and reduces the probability of failure in the future
-> motivation is sustained
Feature roll out
CELEBRATE ALL VICTORIES - BIG AND SMALL :)