How would you feel if you knew that your bedtime habits were being used to predict the effects of natural disasters?

A few years ago, I attended a networking event in Berlin where the topic of anonymised data collection was discussed.

One particular speaker told a story of how Jawbone wearers in the Bay Area reacted to the Napa earthquake in 2014. By collating the data received from the Jawbone devices, they were able to draw a picture of how widespread the shock of the earthquake was felt, and thus revealing the spread of the event and how people were affected.

They were able to see that 93% of Jawbone wearers living within 15 miles of the epicentre of the ‘quake woke up at 3.20am, and 45% didn’t go back to sleep for the rest of the night.

The reaction to this story divided the room immediately!

Half of the attendees were outraged at what they saw was a violation of intimate information (this was data that was collected directly from the wearers beds after all I suppose!), and the other half of the room marvelled at the wonder of this kind of insight, and brains whirred with the practical application of this level of data analysis.

I was in the latter category.

After all, what was really taken from the Jawbone users that would leave them feeling vulnerable?

There was no personal information, nothing identifiable, and nothing that can be used against them. I’m taking an educated guess, but I would think that the only data that was used to produce these remarkable figures were ‘location’ and ‘movement’ (although technically, any physics fan will tell you that you can’t accurately measure both of these things at the same time without breaking the uncertainty principle…)

People are right to be guarded about their personal information, absolutely. Most of it is treasured, valuable and, well, personal.

But would you have felt violated if you had been one of the Jawbone wearers in California that night? Knowing that without giving anything away, you have inadvertantly helped scientists gain a better insight into natural disasters?

I sure wouldn’t have minded.

This is just one example, but there are countless others which show how mediated, anonymised personal data can potentially unlock new insights and tell us more about how we, as people, act within and react to, the world around us.

Google Maps, is another great example. They use anonymised data collected from their iOS app on iPhones, and location data from Android devices, to warn drivers of upcoming traffic problems and suggest a better route. I would wager that more than half of us have benefitted from this kind of service in the past, and it wouldn’t be possible unless your data was anonymously shared.

Jawbone and Google are not the only tech companies who collect this kind of data. Most, if not all do. Often, this data is collected as a by-product of another function; location information from an iOS app, shopping trends for an online store etc. This data is then stored and then left unused.

The real power comes however, when these data sets are combined. What if the Jawbone data was compared with that from energy companies, medical centers or public transport operators?

We could get an even more holistic view of how people respond in this kind of scenario, and be able to plan and react better in the future across the board.

Bringing together different anonymised data sets, can provide us with real insights, with real world applications being the benefit.

Maybe it’s time for us as individuals to rethink the anxiety we feel about how some of our data is shared, but maybe it’s also time for more companies like Jawbone and Google to use the rich pool of data that they collect for the greater good.

Shared, anonymous knowledge, when used in a responsible manner, can only lead to great things.

Every  software company that I have worked with over the years follow a similar cycle when it comes to release cycles. You plan, you build, you Alpha, you Beta, you release.

I’ve always had a problem with this. The first time that you’re getting real feedback on what you’ve built is after you’ve built it!

By this point, it’s often too late to do anything about it. You may pick up bugs during Alpha/Beta testing that you are able to address before release, but what about the product itself? What about the design and workflows? If you’ve made a major mistake in those areas then you more than often won’t have time to fix it before release.

The problem is that a lot of projects will have Alpha and Beta testing written into their project plan. If that’s the case, then there is only a finite time allocated to it. If a major design flaw is recognised at this stage, then it either won’t be addressed, or the proposed release date is moved back. This is because Alpha and Beta testing is usually loaded onto the end of a project.

So why do we do this? Why do we ask customers, partners and other friendlies to give us feedback on something that we may have built months ago? And then, more often than not, have to ignore any feedback because we don’t have the time to address it!

There’s a better way.

Feedback should start at the beginning of a project, and not just within the development department. As soon as you have an idea for a new product, or an improvement to an existing one, you need to start the feedback cycle straight away.

You will hit key milestones in a project way before you have a finished product:

• Initial Requirements
• User Stories
• Wireframes
• Slice plan
• Showcases at the end of each sprint

These are just some of the points that you will reach (or should be reaching) in every project, and it’s at these milestones that you should be sharing what you are doing.

If you’ve made a colossal mistake in your wireframes, or you’re not hitting the right user stories with your project, then you need to know before you start developing, not six months later!

It might not be anything major that you’ve missed, but if you’ve planned well up front then you should be able to give your stakeholders a good picture of what you’re trying to achieve. If they agree, great! You’re on the right track!

You don’t have to have a fully working prototype that people can get their hands dirty with. Talk them through some early features or designs, get their advice on what you’ve proposed on a high level. If you ask someone for their opinion, tell them that their advice is appreciated, very few will turn you down!

And don’t keep it internal. Remember, you’re not building software for yourself, you’re building it for people to use, enjoy and  to make their lives easier.

Speak to customers, partners, industry experts. Speak to people who have used your previous products (if you have some), but also speak to people who have never used your products before. Get a wide spectrum of audience so that you get a varied range of feedback.

A common mistake is that you have to act on everything that’s fed back. Not true, although you do have to listen to every comment, you don’t have to implement every suggestion (you’ll more than likely get conflicting points on some aspects anyway).

Instead, look for themes and patterns across the board. If three separate groups are raising the same concern, then it’s likely to be a genuine one. If somebody is asking for a feature that goes against the vision for the product, then it’s ok to let them down, as long as you explain why.

Keeping this feedback loop open and getting people involved early will help everyone. It keeps the project on track, keeps confidence high in the development teams and also helps your key stakeholders feel appreciated and involved. These are the people who will be giving you free advertising once your product is available after all.

If your feedback cycle starts early, and continues throughout the life of your project, you can be guaranteed that you are releasing the right product at the end of it.