The commonly-held belief among digital product teams (and one that is given a thorough treatment by Travis Parsons on the Castle blog) is that “a digital product will never be finished”. Once an MVP has been taken to market, further investment will inevitably be required to incorporate the learning that is gathered through real life usage. Feature roadmaps will be groomed and systematically implemented. In contrast to a tidy, waterfall project where a series of interdependent activities constitute a discrete package of work with a definite end date, digital projects involve continual iterations towards more value.
We have long been loyal proponents of that view, and have not missed an opportunity to demonstrate the benefits of such an approach within ELT.
Challenging our assumptions
That’s all well and good, however, until you encounter a digital project that does not feel the same way. More specifically, a project that has finite financial resources and an unpredictable future in terms of the team working on it.
This is the predicament that Jo Sayers and I found ourselves in back in December 2016 when we kicked off a three-day workshop in São Paulo with the British Council. Through the latter half of 2015, the British Council had partnered with ADESAMPA (a not-for-profit social enterprise that promotes the implementation of development policies in collaboration with the São Paulo Municipal Department of Labor Development and Entrepreneurship) to develop a programme for encouraging professional development among creative entrepreneurs from the city’s more disadvantaged suburbs.
The Criado em Sampa programme
The programme was in response to the fact that millions of São Paulo citizens living in these vulnerable areas were commuting over 2 hours each way into the city as there were no real opportunities for them to work within their own communities. This in turn served to perpetuate the undervaluing of individuals from these areas and the cultural and economic contributions they are able to make to communities.
Jointly funded by the Newton Fund and ADESAMPA, the partnership launched a series of workshops based on NESTA’s entrepreneurial toolkit methodology called Criado em Sampa – Created in São Paulo. These workshops were attended by over 250 entrepreneurs across the city.
The next phase of the project (and the one we were to begin contributing to) was to make these materials available online and accessible for as many entrepreneurs as possible to extend the reach of the programme, whilst also providing additional support for the first cohort that might benefit from revisiting the course material as and when they needed to.
The issue that arose very early on in discussions was that the future of the project and the individuals collaborating on it were uncertain. ADESAMPA’s on-going contribution felt tenuous as they were waiting to see whether the mayor-elect of São Paulo was going to replace key individuals at the organisation with people from his own circles. It was also clear that there was not going to be any more budget available beyond the initial build stage.
As a result, this digital project was going to finish.
How to handle a digital project that is going to end
So, how do you plan for optimum impact with scarce / non-existent ongoing funding?
You put yourself between the solution and the conversations taking place around it like a bodyguard protecting their client from an unruly mob. Here’s how we went about doing that …
1. Watch out for conversations about what the product could do
As the potential scope of the product begins to reveal itself, it’s easy to fall into discussions around possible features, add-ons, or extended applications. When there is already a red flag around on-going maintenance or dev work, it was crucial that whatever solution we arrived at was all tied up and ready to rock by the end of the build. As such, we became super-alert to any comments about the product’s future beyond that point.
Something that really helped with that was making sure that on Day 1 we captured the high-level mission and the most pressing problems that needed to be solved. These, in combination with an excellent set of user personas, meant that we could easily draw attention back to what was actually needed to be done for the solution to be a success. Typically, we were looking out for:
“… maybe we could … “,
“… just in case”,
“… we’re thinking about possibly … “
“… we might use it in the future, so it would make sense to include that feature now…”
2. Less is more. Do one thing – THE thing – right.
What helped us arrive at our solution was filtering out any features that did not directly deliver on the minimum requirement. It became all about preserving the underlying problems that we were addressing and not allowing aspirations or imaginations to contaminate feature discussions. The consensus within the project team was that, if we only have one shot at this, having a final product that excels at one thing is infinitely preferable to one that does a range of things only partially.
Furthermore, we insisted that we avoid building the platform solution to allow further functionality to be added at a later date. This would use invaluable project management and dev time but not deliver any value whatsoever in the immediate future. Want to make sure it’s ready to handle an e-learning assessment piece that you might want to roll out in six months? No can do. If it’s not being used now, we don’t do it now.
Mean? Yes. Effective? Very.
3. Prioritise stability over functionality
Knowing that there is no budget for ongoing developer or maintenance work really does sharpen the senses. It meant that we assessed possible platform solutions based on whether they were likely to have updates that needed installing, or required a number of plug-ins that might increase the chances of something going awry. We needed something we could set up and leave, even if it wasn’t as sophisticated in terms of functionality as other offerings. A working platform is better than a broken platform with all the bells and whistles.
Why we should treat each phase of a product build as if it were the last
Sometimes, digital projects can and do just finish. When faced with that scenario, the focus needs to be on how you can deliver the most value possible whilst assuming that you’ll never get to work on it again. Interestingly, however, we’re finding that working in those circumstances helps to make all of the normal product development processes even more meaningful. Our collective game is being raised, as it were. Our user personas are more vivid; our list of MUST HAVES is super lean.
What emerged as a result of this set of circumstances was a revitalised appreciation for the product development process. There is an argument, we feel, for treating each phase of a product build as if it were your last, even if there is budget to sustain an iterative product development process. This doesn’t necessarily have to be exercised in the decisions you make about your features (don’t intentionally build dead ends when you know that you don’t need to, for example), but more in the mindset of the team.
Cover photo by Bethany Legg: https://unsplash.com/@bkotynski
