Skip to main content

Regenerating ProdPad: Risking a Re-write

Posted by Simon Cast
October 2, 2014

Our ProdPad Regenerated project is a regeneration in every sense of the word. Much like the Doctor, we’re not just changing how we look on the outside, but the inside too. Even if the “soul” of ProdPad remains the same, (non-UK or cult TV show-watching readers can take a quick Doctor Who crash-course here) a complete end-to-end rewrite will change the platform at its core.

This kind of rewrite is widely, and understandably, considered a risky proposition. In fact both Janna and I have believed in the past that rewrites just don’t work. So given this high level of risk, why did we settle upon a complete re-write above iterative development?

Making our decision

As Janna has pointed out in previous posts on this project, our decision for a rewrite wasn’t driven by technological newness but was a considered response to the challenges and opportunities that ProdPad is moving towards. As we explored what we wanted to achieve with a rework of ProdPad, the possibilities of a front-end re-write to us – as opposed to the iterative UX improvement we had initially planned for – became quickly apparent.

But that alone wasn’t enough to justify the complete re-write of ProdPad.

As well as improving our approach to ProdPad’s new UX, this approach would also help us more effectively reach additional business goals that we have planned for the next 6 months to a year, including:

  • Migration to Symfony2 and Doctrine2
  • Increase the performance of ProdPad for users
  • Support for native iPhone and Android apps
  • Removal of barriers to on-going innovation

It was only after we had satisfied ourselves that the re-write would achieve multiple important business goals that we decided to risk a re-write. The possibility of hitting so many goals made this rewrite a golden opportunity; and the potential benefits far outweighed the associated risks.

Managing the risk

With a decision like this comes the risk of lost time, wasted resources, and things generally blowing up in your face. While you cannot eliminate the risk of this big undertaking; you can work to reduce the unnecessary risk that might come with it.

If you’re thinking about a re-write of your system, there are two broad areas of risk to consider:

1. Technical

To reduce the technical risk we chose to go with technologies that were new, but not on the bleeding edge. Bleeding edge technologies create risk because you end up having to write many of the fundamentals and common code and despite promises made there’s no guarantee the technology can do what you need it to. Instead we looked for options with a strong community whose members had already done much of this groundwork and offered reassuring social proof.

2. Scope

Scope is a nasty risk that can often be the major cause of a rewrite sink. Scope risk starts with “Well since we are here…” or “As it is taking so long lets just…”. This marks the beginning of a scope creep that all too often bloats a rewrite unless a product manager is firm. Both Janna and I were very clear about ensuring that the re-write didn’t introduce new features but focused on the UX improvements and underlying architecture improvements.

Rewrite or iterative development?

Re-writes can and all too often are risky bets that fail. So it’s very important to establish when you should build small and iterate, and when you should take the plunge to start over. Building out an MVP is an experiment. It’s a way to prototype to find out if you’re building in vaguely the right direction – what’s the least you can do to learn the most about what’s best?

For ProdPad, we’re well beyond proving a need or a market: we’ve already got a few hundred customers on board, and have had feedback from the thousands of users who’ve used ProdPad over the months.  We’ve progressed beyond the point of testing new functionality to try and capture the market. Instead, we need a solid base to build on. We need to solve some seriously tricky architecture problems before jumping into the world of real-time collaboration or building a native mobile app. And we need something that’s fast and efficient for our users and for our development team to build on.

We wanted to revolutionize the ProdPad UX and it is almost impossible to do that well iteratively. To create that revolution we needed a definitive break with the past.

If you are thinking of embarking on your own re-write, I suggest you keep the following in mind:

  1. Will it meet multiple business goals over the next 6 months to 1 year
  2. Can you prove the business concepts that your rewrite project assumes?
  3. Are you able to by avoiding bleeding edge technologies?
  4. Have you developed a tight and efficient scope?

If you’d like to hear more about our ProdPad Regenerated project, you can get in touch with us – and even find out about getting onto the beta program – here

Sign up to our monthly newsletter, The Outcome.

You’ll get all our exclusive tips, tricks and handy resources sent straight to your inbox.

How we use your information

Inline Feedbacks
View all comments