The world is full of ideas. As a top-of-the-line supplier of software design and development services, Jayway has a lot of discussions with clients and potential clients about ideas – theirs and ours. But while ideas are all around, the ability to make ideas come alive in digital experiences is certainly not.
So, what does it take? Below I have collected a number of things I find are extra important to pay attention to. Naturally, there are a lot of other things too, and as always – there are no silver bullets.
1. One Team
The team is who is going to make things happen, success rides on their motivation, creativity and well-being.
So, please don’t give the team a backlog of tasks to complete! Give the team a juicy real-world problem to solve. A problem for users, the solution of which is important to them. Ironically, often teams will actually ask for a well-specified backlog, but this is just a sign that they are too removed from the actual users.
Don’t make decisions on behalf of the team. If there is no really good reason that the team cannot make the decision themselves, let them do it. Let them get to know the problems of users and come up with their approach to solving them.
To solve real problems for real users, the team needs to be cross-functional. All competences needed to design, develop, verify and validate solutions to real problems, need to be part of the team. Any handover should trigger an urge to get rid of it. Why not make the Product Owner part of the team and have the team define its own roadmap to creating value?
2. Measure Value
Features do not have a value in themselves, only if they solve problems for users they do. A team’s progress should not be measured by completing a backlog of features. It should be measured by creating a value when it is being used by the users.
“If you want to make God laugh, tell him about our plans”
– Woody Allen
We have a lot of ideas about how we can make the lives of our users easier. We have plans. But we also must have the humility to realize that we are only making assumptions. Even if we ask our users what they think we cannot get rid of the assumptions.
Features are what the team produces. Ideally, we want the features to lead to changed user behaviour and in turn to a value for the users and other stakeholders. Until this is proven, this chain is nothing but two big assumptions.
It is not easy. It is the most difficult item to crack on this list. But the team motivation created by feedback from real users is extreme, and the creative powers it sets in motion cannot be overestimated.
3. Into Production
It is never too early to start learning, and bringing our product into the hands of real users is ultimately the way to do this. It is the final check that we have turned our assumptions into certainty.
“If you are not embarrassed by the first version of your product, you’ve launched too late”
– Reid Hoffman
Don’t confuse this with creating a crappy product. But not until your product is in the hands of real users, using it to solve problems that are important to them, will you get a fair assessment if you are doing the right thing.
And there are many other reasons to get into production. Few things kill motivation in a team as efficiently as their success being dependent on tasks buried in other teams’ backlogs. We all need control of our own destiny. Going into production early and often will make such harmful dependencies painfully apparent.
Making this happen is going to be your most important challenge when creating our product roadmap – finding the easiest and simplest way to provide actual value to real users under real conditions.
4. The Power of Small
Building digital experiences is really a fairly chaotic enterprise. Allegedly, the Swiss architect Le Corbusier would never let clients into the workspace where the creative process took place; this would just make the clients very worried, undermining their trust and make them want to take control of the process. These processes show similarities with combat, and as the Prussean general Clausewitz claims: war (and I would say product development) is an environment in which getting simple things to happen is very difficult and getting difficult things to happen is impossible.
Our only option is to do simple things – small things – and repeat over and over: Solve problems with small solutions. Bring our small solutions to our users. Validate that we have actually created a user value.
Trying to do too much at once is placing one foot into the fabled tarpit, making it tempting to throw more bodies onto the problem. The complexity of collaboration increases exponentially with the size of your team. Small, maximally independent teams will always yield maximum outcome. Better to keep our cool and let our small team do its job, the alternative spells disaster.
Everyone knows this, but simply knowing it is apparently not enough to stop us from creating these types of problems by creating overblown roadmaps and elaborate plans.
5. Win, One Battle at a Time
Efforts to solve too much at once is in vain; so is solving everybody’s problems. That would be trying to make something difficult happen (as Clausewitz would have stated it) and it will simply never get done. Focus on solving problems for one very limited group of users, one specific market or even one single person. Win over supporters who will promote our product to their peers and to your stakeholders.
Make the smallest possible solution that provides value for the smallest possible target group. Make the target group feel part of the process. Talk to them. Respond quickly to their wishes. Make them feel like they are the centre of your universe. This will create the level of trust needed for the team to do its job without falling into the trap of promising features to be delivered at a specific date.
If we manage to solve real problems for one single user, most likely others will be knocking on your door. See what is the smallest thing you need to do in order for them to adapt our existing solution and as long as it is in line with your overarching goals, give it to them.