Planning Your Product Development Work
Over the past couple of weeks, I have been formalizing how we do product development at my work.
Today, I want to share with you some thoughts we had around a task that is often overlooked or rushed: planning.
Imagine you are building a software product, and you are in front of a new problem you want to solve for the user.
How to plan your product development work?
The act of planning is to break down the work in front of you.
The best tool for planning is a whiteboard and a pen. Start at the highest level possible. As you should strive to follow the lean pattern, in most cases you will have 3 categories of tasks:
- learn about the problem
- build a first piece solution
- measure and get feedback
Planning can be painful and you can get stuck. But it is when it becomes difficult, that you have to put your head down and stick to doing it. If you need help, bring one of your more experienced colleagues in front of the whiteboard with you.
One of the overlooked benefits of planning is that gives trust into what you are doing to yourself and to the rest of the team. When you have a clear plan, people will trust that you are moving towards the goal and are not just wandering around.
- What do you think?
- How do you tackle planning for your product?
It's true that one of the primary functions of product planning is to give a sense of direction to the team. It's huge for morale and fosters collaborative problem solving because the team can generate ideas based on where the product is going and what problem it is solving.
The way I approach planning is somewhat different depending on whether I'm working as a member of a larger team or just on my personal projects but one thing remains pretty much the same: setting limits.
You need to scope the solution in such a way that it only tackles the core problem you're trying to solve. Setting limits to what needs to get done prevents the project from dragging on forever, which kills team morale and you delay getting real user feedback.
This is not something that should be done at the start of the project and then forgotten about. It needs to be done whenever new tasks are discovered during implementation and is only possible if you have a clear idea of the problem you're solving.
It's challenging as it can create tension between team members or, if you're working on your own, a sense of insecurity about whether what you're building will not seem too feature-light to the users. But it does help to prevent some feature creep even if you don't always prevent all of it.
Many firms have some proven methods to follow. If there is product to market fit, then you move to a Product Break Down Structure . If there is no product to market fit you need some "proof of concepts" in code. I have done enterprise software at the largest scale and in addition five SaaS products.