Crowdsourcing work - or how to create a backlog when nobody has asked for features

Collectively deciding on what work to prioritise is a powerful way to harness creativity and drive innovation.

You’ve had the right conversations internally to figure out what matters most to your business.

You’ve thought about outcomes and impact and didn’t fall into the project trap. You even phrased your outcomes as hypotheses “We believe that [doing X] will result in [Y happening]”.

You considered what success would look like and how you might measure that, avoiding the common pitfalls where you can (but understanding that these things don’t have to be perfect to bring value).

You assembled what you believe to be the right teams with the right skill sets to be both autonomous and successful.

Great! Now what?

If there’s no groomed backlog to fall back on, no requirements document, no prioritised feature list to tick off, and - shock horror - no Jira tickets to call your own... What do you do next?

Depending on the level of experience in your teams and the entrepreneurial predisposition of its members, you may find that some teams take like ducks to water while others are proverbially frozen with fear. Autonomy is a lofty goal to aspire to, but (sadly) not many teams have actually experienced it. Once used to certain guard rails and processes, the idea of making your own decisions - and being responsible for their outcomes - can be daunting.

Psychological safety is hugely important here. That, and acknowledging that nobody knows the answer to our problem yet, or what the solution may look like. They might say they do (yes, you over there shouting about wanting feature X implemented asap) but until we run experiments and measure their impact we won’t know if we’re right, or if there may be better solutions out there than the one right in front of us.

It is important to remember that all solution suggestions are experiments until verified. Experiments don’t fail, they teach us something to inform future experiments. We should try to structure our experiments in such a way that we learn the most amount possible with the least effort required. This is where writing lines of code may initially be superseded by other approaches: speaking to customers, surveys, wireframes, low-fidelity prototypes held together by Scotchtape and blue tack, whatever works.

Let's get experimenting

With your Chief Experiments Officer hat on, what are some things you might try that would allow you to validate - or in fact disprove - your outcome hypothesis?

Ask yourself, “If it were me, my problem to solve, my money to spend - what would I do?” Think beyond your role and consider whatever tasks may need to be done, conversations you could have, research to do. Stew on this for a little while, don’t give up too soon - write down whatever crosses your mind, don’t edit or discard too easily, just let your thoughts run and capture the results in a list.

Once you have a solid list, review the items and see whether any of them could be considered “low effort, high impact” - the most amount of learning for the least effort and/or time spent. It hopefully goes without saying that we don’t want to spend too much, if any, time on the low impact options - but don’t disregard your “high effort, high impact” options either. Instead, let’s spend a bit of time thinking about those.

Timeboxing to the rescue

What is making these options high effort? Are there organisational hurdles, regulatory issues, technical complexity to even get to proof-of-concept? Let’s use a little helper called “timeboxing”. Fix your duration and give yourself a time constraint to see what solutions may arise. Constraints provide focus, a creative challenge “to search for and connect information from different sources to generate novel ideas”.

What could you accomplish if you only had a month? Can any of the hurdles you perceive be overcome in that time? How? A month is a sufficiently long time that you will probably arrive at a few ideas to try. Great! Write them down.

Now let’s assume you only have a week. Imagine you have this great start-up idea and the perfect angel investor is in town at the end of the week. How can you best use your time between now and then to learn the most amount possible to give you sufficient conviction and gravitas to secure their endorsement? The same rationale applies within your organisation - even though it’s less explicit, you are effectively always competing for funding with other teams and departments. What can you learn in a week?

And finally, just for fun. What could you accomplish in a day?

Go, go, go

By now you should (hopefully) have a reasonably long list of experiments to run. Great!

As a team, select as many of these as feasible to run in parallel without stepping on each other’s toes or ending up spread too thinly. The goal is not to start but finish as many as you can as quickly as possible. Form sub-teams around bigger tasks and be open with the rest of the organisation if you’re missing key skills to help you execute your experiments. Do you need legal input? Or someone from Compliance to advise? Tell people. Don’t assume they know.

And now, finally, you can even create Jira tickets to organise your work if that makes you feel better!! :-)

Good luck! Let me know how this worked out for you - what was the most surprising thing you learned in the least amount of time? Share in the comments, or drop me a message!