Product Development Nightmares
Building software is hard, and missing self set deadlines is upsetting. When something isn't working it's important to understand the problem.
Our company Property Technology Ltd is building a prospect management tool for estate agents www.apply.property.
My business partner Bilal is in charge of development while I am responsible for sales. The expression “can’t see the forest for the trees” fits nicely into the problem that we've had with missing deadlines. On one end of the spectrum Bilal is busy building the product, he’s engaged at the most granular level, writing code, he sees the bark of the tree! At the other end I’m out pitching the grand vision to clients. I see the whole forest from a birds-eye view.
Our current process hasn't linked the two extremes. We've identified this as a gap in our team. We really need a product manager, who takes ownership of each feature release. After a lot hunting we've hired Daniel. As head of product he fits in nicely between Sales and Development. Daniel will be both out meeting with clients, but also discussing technical details with developers. Having him take ownership of the product is vital to us improving our performance.
With Daniel's help we are changing the way we work, we've moved to a Kanban development style. One aspect of this is breaking down future feature releases into much smaller chunks, so timelines are smaller, and accordingly planning errors are smaller and easier to deal with.
We're also improving the tools we use to plan and develop. The first staging is mapping out how a new feature will work. We do this collaboratively using a flow chart tool called Lucid Chart and it looks something like this:
Running through all the steps insures we catch easy to miss problems like: if a user enters a phone number for verification but they entered the wrong phone number how do they then edit their phone number and send out a new verification code?
Once we feel the process accurately shows the full user journey, and we have solutions for all edge cases, we then move to creating a visual mock up on a tool called In-vision.
Getting to this stage is fairly work intensive; it requires a graphic designer creating wireframes, then they use Sketch (mac graphic design software) to create the designs. Sketch links with In-vision to create a demo that can be clicked through. As getting to this stage is so labour intensive it's vital to keep the feature set as simple as possible. Getting complicated with functionality is expensive even in the design stage & it's wildly expensive in the development stage.
We use the In-vision demo to get feedback from clients & to test internally with the team. It really is true that "weeks of coding can save hours of planning". Once we're happy with the demo the designs are then moved to a program called Zeplin.io
At this stage the design work gets heavy. Every the different state of every button needs created, e.g. how does it look when a button is selected? What does a screen look like when it's loading? If there is a failure state what does it look like? These designs are then collaboratively reviewed before being passed to the development team.
The development team take the Zeplin.io designs are start to write up a to do list of all the tasks that need completed in order to build the product. We do this in a tool called Pivotal Tracker. Each action that a user can take is written up as a 'story'.
A developer then marks how difficult a task is to complete by assigning it with a number of points. The difficulty of building each story is reviewed collaboratively to ensure the number of assigned points is realistic. Pivotal tracker monitors the performance of the development team, recording how many points of development work are completed each week. It uses this data to calculate how much work the development team can complete in future works, and thus creates a timeline for product release. All this data is shown on a dashboard.
There are a number of issues with the timeline predictions from Pivotal Tracker. When a developers code is submitted to git hub sometimes it fails. There is a problem with the code and it needs reviewed. Pivotal tries to account for this by reviewing the failure rate of each developer and adding that in as a margin of error into the time line.
The ultimate problem with timelines is bugs. Even when the product is build to exact specification there can be a number of bugs, little issues, that need fixing. There is no way for Pivotal to estimate the number of bugs or plan how long they will take to fix. T
To combat this we're using Crowd Wisdom. Once all stories are entered into Pivotal and assigned to each developer we ask the developer how long they think it will take for them to complete their work. We also ask them how long they think it will take for the whole team to finish their work. We take all of this subjective, guestimated data and then calculate the average estimated delivery date and include this in our plan for when a product will be delivered.
As you can see there is a huge amount of work required to plan a project and come up with a timeline. Not doing all of the above work would be like asking a builder to build you a house without any plans from an architect...
This is a very rough outline of our timeline planning process. There are other processes for choosing which features to build but that is a story for another day!
