So far we’ve covered what the PS Launchpad programme was and what the content of it was. In this post I’m going to start to go into the details of our idea and how we developed it through the course of the 14 weeks of the programme.

Initially the brief that Lucy clobbered us with was that we needed to “do something about all our data”. Our first conversation, as you might expect, was all about where we were now and some of the challenges we faced as a council around the subject – so we covered our business intelligence / data warehousing programmes, our open data initiative, and our new standards around system procurement that mandate open APIs for releasingdata. These things are all good but Lucy wondered if we weren’t missing the point with all this technical stuff, and my instinct was to agree (because technical people usually miss the point of technology, in my experience).

And it’s true – the council has an enormous amount of data but doesn’t do much that’s useful with it, considering. Why was that?


The 5Ws. Source:

So the first few weeks of the project – codenamed Cloche – basically involved us exploring the entire supply chain around council data and asking who really needed the insights it might yield and how might we provide it to them. We spoke to as many relevant people as we could (although there were lots of people we didn’t get round to or couldn’t get access to in the limited time available) and quite quickly started to position our project in relation to what everyone else was doing – after all, no-one wants to be reinventing the wheel. All through this time the crew cajoled us into focusing on the problem statement – what was the problem our project was supposed to be solving and did potential users or customers recognise that as being a real problem?

At this point we were also being encouraged to create what is known as a Minimum Viable Product (MVP). This is basically the smallest, cheapest and most basic thing you can make that demonstrates what a product will do and allows you to demonstrate it to potential users or customers to see if they would use or buy it. The importance of this concept cannot be overestimated – we were testing our idea, not trying to build a finished product, and the whole point was to see if the idea had traction. The two things together – the problem statement and the MVP – are a kit for testing the idea on an unsuspecting world, and once you’ve tested it you need to change it and test it again until the data shows that you have enough traction.

So we reduced our idea down to the smallest thing we could – and settled on targeting local councillors as they are not particularly well-served with data products at the moment but they nevertheless have some quite urgent requirements in terms of what council data could do to help them.

Each week we pitched the latest version of our idea at a group of peers and mentors, and we did our level best to get as much feedback from real users and customers as we could – and all this plus our own reflections got fed back into the next iteration of the idea. Overall we created 14 distinct versions of the product in the 14 weeks of the accelerator programme.

To be honest, though, this sounds purer than it was in reality. Our product iterations show quite a lot of gradual improvements and tweaking rather than representing radically different and new ideas to test each week. I think that we moved from a more general thing to a more specific one as we gradually got our heads around the idea of what an MVP should do and it isn’t until the last couple of iterations that feedback becomes a prominent thing. Nevertheless, I’m pretty pleased with how far we got considering we started with a) such vague ideas, and b) a heavily local government oriented mindset 🙂

At the same time as developing the product in this way were talking to potential users and trying to get a feel for what the demand for the product would be like and how much value it would add. All of this feedback ended up back in the pot for subsequent iterations of the product, of course, but we also had to look at how development could be funded going forward – and nothing was off the table, including commercial models.

The long and short of those conversations and analysis was that there are a number of valid business models for the idea, and that a commercial model would be achievable if we could actually get funded to build and ship the first version. At this point the Local Government bits of our brains kicked in and so we didn’t go as far as actually trying to sell it for real – I’ll say much more on this in a later post in this series.

At the time of writing our MVP is live and you are welcome to check it out and leave feedback. Please bear in mind the definition of the MVP as stated above – “ the smallest, cheapest and most basic thing you can make that demonstrates what a product will do…”. Now that we have the basic thing, we need to use our testing and feedback to work out what to do next…..

Next: next steps for the product