Posted by Massimo Sgrelli in
Whodo.es -
comments are closed
We just finished launching WhoDoes and soon we will be starting to think of the next major steps in our product life cycle. New features? A bit of mashups? APIs?
Not exactly. We decided to take a different approach, re-thinking some core characteristics of WhoDoes to make it even easier to use. We know we are the first clients of WhoDoes and we soon understood that we would make a better product for everyone by simplifying the way it works.
So we stopped thinking about the product’s evolution and we started thinking about how we can streamline what we have been creating.
We are a small company and this is an advantage. You can simply decide to change things that you think can be done better and soon, start to improve the future of your application. You can decide to listen to yourself and your customers, and make things work faster.
No committees, no meetings, no focus groups, ... no wasting of time. The best way to check how changes might effect your product is to try it on your user base and to wait and see what it produces… in the real world.
I think user responses are the best way to validate ideas.
Anyway, let’s go through what we called Lesson Learned #1
No constraints, no boundaries. You can step back
In the current version of WhoDoes people have to follow a specific pattern to start planning a project. You have to create a new project, invite then staff people, create milestones then tasks and assign people to tasks.
This is the normal path you follow when you start a plan. Up to this point everything can be considered normal.
Using WhoDoes you also need to complete all the task’s attributes (i.e. start and due date, budget) in order to make them visible on people’s calendars. If you don’t complete them, you don’t actually get the tasks included into your plan and visible to people.
We found this approach too limited. After all a project management tool must first of all help people to communicate deadlines, things to be done or simply facts.
People need to share TO-DOs in a project even before they know who will be in charge of them. Again, they need to communicate to each other before knowing when activity deadlines need to be accomplished.
So the first decision is. Relax requirements on mandatory attributes and objects and make milestones and tasks loosely coupled.
Tell us what you think!
Permalink
I am currently working on Migrating 
Many compliments to Dan Cederholm of 
