(This article was originally published on Wired.com.)
I recently had a chance to participate in the MIT Media Lab’s “Make the Breast Pump Not Suck” Hackathon.
Having observed my wife’s occasional pumping for our kids, I was in tune with some of the issues associated with pumping and was excited to work on improving these devices. I was also curious to return to the Media Lab, where I had developed E Ink when I was at MIT. I was happy to see that it still has the same great mixture of artful nerdiness, high standards for work, and intellectual openness.
As someone who does product development professionally, the hackathon intrigued me as a method of innovation. We routinely run internal brainstorms and prototyping sessions at Bresslergroup with our teams, but there is generally more preparation, more time, and more iterations.Most notably, the teams include people from our consultancy alone. What could a group of strangers accomplish in a couple of days? What would we be able to build without the ability to have things fabricated except with what was on hand?
A hackathon is at least partially about surprising people with what’s possible in a short amount of time, and I was surprised at what we accomplished. I left wondering how we could build aspects of the hackathon into our design practice.
Hacking the Product Development Process
The idea of more open design and more inclusion of people in the process isn’t an obvious fit for what we do. Product development consultancies as well as companies doing internal product development tend to be secretive about what they’re up to, and for good reason. There is a tough landscape of competitors, critical intellectual property issues, and the need to innovate before the other guy. The flipside to this is that we highly value outsiders’ opinions and do user research whenever possible to get feedback from real users on the design.
Crossing this divide seems like an interesting opportunity. I’m not just talking about “co-design” in which users are led to design their own solutions. I still expect us as designers and engineers to lead the effort, but how do we broaden our team and deformalize some aspects of the process? In the spirit of brainstorming, here are some ideas for how to hack the more formal product development process:
1. How about we …. work only with what’s on hand? Our team’s inspiration was to make a nursing aid that would assist in manual stimulation of the breast. The hackathon was a closed room — during that weekend, we couldn’t source anything external. The organizers furnished a table piled with materials for prototyping. We fiddled with fabric, heat welded plastics, and experimented with hydrogel beads. Two disassembled breast pumps, an Arduino, and some motor controllers let us inflate sectioned bladders in sequence to simulate the typical hand movements a mom uses to fully drain her milk ducts. Sure, it was a rough prototype. But it communicated the concept much better than any sketch or rendering would, and it showed how the real product might come together.
Being limited to the tools at hand is an interesting constraint. You end up reaching for the tried and true or adapting your design. In some cases it leads to quicker innovation. At Bresslergroup we always send out for castings when we’re making silicone parts. But for a recent project, the development of a medication applicator, we cast the parts in-house and were able to work through four iterations in a week — the prototypes were really rough, but it meant we solved the problem in one week as opposed to being delayed by waiting for castings to come in and solving it in four.
2. How about we …. institute faster and rougher prototyping cycles with very tight schedules? Prototyping is cheap, so let’s do it more often. Let’s implement scrum for hardware.
Our consultancy recently designed a smart sports device in four weeks, which was considerably less time than we typically have for similar projects. This forced us into developing along very small but increasing loops and we prototyped during each. Product developers could self-inflict these kinds of timeframes on themselves by asking, What can we do in one day? How about three days? Seven days? Three weeks?
When I quote a project I always put prototyping up front before the engineering phase is complete. Of course this is tough to do with a very complex device, but with others, why not produce a prototype five days into development? It can be very rough, but it’ll help work out early problems.
There is an increasing level of sophistication that correlates with building prototypes early on. It’s parallel to printing an early draft of something you’re writing. Being able to see how it looks and feels — the pacing, the word choice — and reading it aloud early on will ultimately help it progress a lot faster.
3. How about we …. start by pretending nothing’s off-limits? No constraints. At the Breast Pump Hackathon we applied ourselves without any concern for regulatory issues, cost targets, or even infringement of existing intellectual property. Honestly I found the lack of constraints to be incredibly liberating. I’m used to keeping myriad factors in mind that limit the possibilities for new designs. During brainstorms we free ourselves from many constraints, but at the hackathon I felt like nothing was off limits.
In reality we can’t push constraints aside completely, but it’s possible to keep things even looser during the brainstorm phase. There’s value in giving people time to think freely about a problem. There’s value in putting the FDA approval requirements for a class 2 medical device on a shelf at the beginning of the brainstorm. Follow the mantra of “Yes, and …,” and don’t let constraints get you stuck.
4. How about we … divide into multiple independent teams working against each other? The Hackathon started off with people pitching ideas and from there everything magically coalesced. Teams formed, ideas were debated and improved, and people started tinkering. Some people worked on the hardware, others worked on presentations, or carried out research. Logos and slogans were whipped up, voted on, and approved. I found my team to be open, democratic, and efficient at making decisions.
The competitive aspect of the event — judges rewarded four top teams with prize money — was just enough to get great results but not enough to hinder discussions. A light amount of friendly competition is good for getting people to work a little harder. The friendly competitive spirit seemed to catalyze ideas. What if we transferred this to a consultancy setting by dividing into small, multidisciplinary teams and rewarding “winners”?
5. How about we … embed our development teams with user “agents”? The people I met at the hackathon came from a wide range of backgrounds. Some were designers and engineers, but many were moms with only one goal: a better pump. Though many didn’t have design or engineering backgrounds, they were product category experts who possessed the most intense motivation: a personal one. I was impressed at the diversity — this was not the normal crew that shows up to a software hackathon.
The users, i.e. the moms who use pumps every day, brought all kinds of inspiration and knowledge to the group, including their own experiences with pumping and with other devices that had useful mechanisms. Having a team that was not just made up of designers and engineers gave me pause.
Feedback didn’t have to wait for a formal user research session but could be asked for and received right then and there. The range of opinions was so interesting and different and varied — rather than waiting for user feedback to see how people might try and turn the device you designed upside down, you’ll find out right away.
A Better Product, A Better Process
In the end, my team was able to make a working prototype in only a few hours, and came in second place. It was very clear to me that the most lasting impact of the event was the attention it heaped on the product category. For breast pumps it was the news story of the decade — high profile outlets including CNN, The New Yorker, and the Huffington Post ran stories about it. Which is pretty awesome — it’s an important piece of equipment and a lot of people have issues with it.
For me, the experience was also valuable for giving me the time, space, and inspiration to think about how integrating elements of this hackathon might lead to a better design process.