So, you think that it might be good for us to work together, but you want to where we take things from here? This is the page for you.

If you’ve got your processes sorted, I am pretty adaptable, but here is how I advocate working. It’s inspired by many strong engineering practices¹, and Behaviour Driven Development. It sits nicely with the double-diamond design approach too.

A. Define what success looks like in terms of business value

I’ll want to know what you want to achieve for your own business; how will you measure whether this is a success for you?

Some possible metrics for early-stage startups could be:

1. Get a certain number of first users on board.
2. Generate a certain amount of revenue, or pre-orders.
3. Satisfy an investor or other key stakeholder that progress is being made.
4. Achieve an investment round.

For an existing product, this could be:

1. A certain amount of user growth.
2. A certain amount of revenue growth.
3. Improve engagement (Daily Active Users for example) by a certain amount.
4. Improve customer satisfaction by a certain amount.

Together we will write down some success metrics and we’ll have a clear conversation about where my responsiblities lie relating to these.

B. Write down the first and most obvious pain-point to solve or enrichment to add to our users' lives.

It’s one pain point. We’re going to solve one problem. Or add one enrichment. In one sentence, we’re going to describe it.

This is the ultimate minimum product.

It might take a few days of mapping out the whole problem space, and finding that one thing. So we can use things like user interviews, focus groups, social media sentiment analysis (for consumer products), to get good information. We can use affinity mapping², and get a really solid idea of where the big problems lie.

We can hone it down with tools like the Kano model to discover what will really delight our users.

Once we’ve got to that one problem, we will write it as a single user story.

“As a cyclist, I want to know my cadence, so that I can train more effectively.”

C. Design at least two behaviours to start to address the one user story.

For all the problems I’ve ever come across, there are multiple ways to satisfy a user story. For the example above, I can imagine a host of ways:

1. Install a traditional cadence sensor on the bike, and display it on a screen.
2. Use a camera to watch the cyclists' legs, feet, or pedals, and count the cadence, display it on a screen.
3. Either of the above, and speak it through a speaker or earpiece.
4. Get someone to cycle alongside the cyclist and estimate the cadence, and shout it over to them.
5. Provide a regular beep for the ideal cadence, so that the cyclist can estimate whether they are going slower or faster than ideal.
6. Same as previous, but with a flashing light or display, or a vibration.

Some of these solutions would be easy to implement, some would be hard to implement. They will have differing costs of development and implementation.

Somehow we need to make a choice, and the best option will be the one that fits our users' current practice and environment best. Given the amount of exposure that we’ve had to our users in the first step, we will hopefully have some idea of how to at least narrow it down.

Before going back to users, we will select at least two of these. Why at least two? It’s exceedingly difficult to get feedback on just one solution. People don’t like criticising something that is fully-formed. But if you’ve got two solutions, then they can see that you’re not complete, and they will be more willing to feed back.

It’s good at this stage to write down our intention for these behaviours with some nice BDD-like examples. Here are some for one behaviour set.

“Given that my speed is 10 miles per hour, when I select ‘Maximum Efficiency’, the device will beep at a rate of 60 beeps per minute.”

“Given that I am stopped, the device will not beep.”

“Given that my speed is 15 miles per hour, when I select ‘Maximum Efficiency’, the device will beep at a rate of 100 beeps per minute.”

D. Prototype and test the chosen behaviours; and final design.

Pretty straightforward, right? We will build the two behaviours, and then get some feedback from users.

Depending on the maturity of the product, and the environment, we will either build this out properly, or prototype roughly. E.g. if we’re dealing with moving user’s money, it needs to be solid; if we’re simply manipulating information about user’s money, it can be less perfect.

Then we take it to users and test it. User interviews, short testing cycles, that kind of thing. If we’re building on an existing product with a number of users, we can integrate it into their experience, and see what difference it makes to their satisfaction and behaviour.

At this stage, we’ll be in one of these situations:

1. Clear Winner - we can select one way of solving the problem. In this case, we go on and build it as designed.
2. Near Winner - we can adapt one of the designed behaviours with the user feedback. So we go on with adaptations.
3. No Winner - we need to go back and find another way of solving the problem. We need to go back a step and try again.

E. Build the selected behaviour.

Now we build out the selected solution to the level of integrity required for a final product.

I’ll use the best possible technology for the solution, follow strong Test-Driven Development protocols and a fair bit of Extreme Programming³ to ensure a lean, well documented, reliable and adaptable product.

If we need to bring in other experts, I’ll lean on my network of software developers, mechanical and electronic engineers to support. I’m never afraid to admit when I don’t know something; in my view, a combination of humility and ambition builds the best products.

F. Measure and Iterate

Once we’ve done all of the above with a single behaviour, we can go around the cycle again, in the new context of having something users can start to have a go with.

At the end of each iteration, let’s make measurements on the business metrics. They might not move a lot at the end of the first iteration - but let’s keep going, we’ll see things move over time.

Conclusion

If that sounds good then let’s talk! I’m a fan of meeting in person or on video-call; you can book a call with me here. If you’re in Cornwall, UK and you want to go for a coffee, then do get in touch.