Area 631: what I learned in IBM’s start-up and innovation program
or how to run your own 3-month prototype sprint on a multidisciplinary team
First Off, What is Area 631?
In short: a team of six are given a problem, a client, and 3 months to design and build a working prototype or proof of concept. That prototype can then be launched as a IBM funded start-up via Hyper Blue or be freely implemented by the existing client. Here’s how the creator of the program describes it:
“At large enterprise companies, R&D can sometimes take years to go from theory to application. To disrupt this process, IBM created an internal incubator called Area 631: 6 IBMers working for 3 months to generate 1 breakthrough. IBM gives small, agile teams full control and full-time commitment to their project — with three months to go from a big idea to working prototype.”
— Steven Astorino, Canada Lab Director
In my case, the Area 631 project completed in July of 2021. It then went on to become an IBM owned start-up named Conclude.ai . Unfortunately, pending patents prevent me from speaking about product details (sorry!). Instead, I can share 3 key insights: how to find the right interviewees, tips for working in a remote multidisciplinary team, and how not to be humble.
Overview of our Unique Project Constraints
A little context before we begin: our team of six came from different technical backgrounds and never met before project kick-off. Our team comprised of:
- 1 full-time data scientist
- 1 design intern (me)
- 2 back-end developer interns
- 1 full-time front-end developer
- 1 front-end developer intern
We also had to contend with working remotely across three time zones due to the COVID-19 pandemic. As such, we spent the first month in video-call meetings every day, but slowed to a single scrum meeting each week to update each other on our progress in the 2nd and 3rd. Here’s a rough outline:
- Month 1: conduct user research, understand the problem, and define MVP
- Month 2: create a feature roadmap, design the UI, and build the solution
- Month 3: keep building, conduct usability testing, and refine
Each month wrapped up with a 20 minute presentation of our progress to key stakeholders, IBM executives, and IBM Fellows. “Fellow” being the highest technical title a scientist, engineer, or programmer at IBM can achieve — only 4–9 appointed each year — so, no pressure!
With that cleared up, onto the three insights!
01: Leap-Frog to Stakeholders You‘re Unaware of…
…and keep in touch with the brutally honest ones
We began by interviewing end-users, stakeholders, and aligning on what exactly we were building. Those interviews were key in proving our Minimal Viable Product (MVP) would be something our users actually want to use. As time consuming as 1 month of interviews may seem — especially to developers who are itchy to start writing code — it is vital to get an accurate picture of the problem before building a solution. (More commonly known as “Getting the Right Design before Getting the Design Right” by pioneer of HCI research, Bill Buxton).
To accomplish this quickly, use each interview as an opportunity to leap frog to the next. Ask each interviewee who else they know might be working on the same problem? Whose toes might you step on? Besides your target audience, who else would benefit from what your building? What red-tape might prevent you from building it? All great questions that could lead you to stakeholders you didn’t know about!
Bonus points if you are able to find a user or domain expert to challenge the more unimaginative or outlandish ideas frankly and frequently. For instance, we were lucky to work with Professor Daniel Ameyot from the University of Ottawa. He is an expert in computer science, innovation, and technology in the legal and health domains. He was invaluable because he brought a critical yet constructive eye to counterbalance IBM’s more business focused goals. In particular, he kept us abreast of any ethical or technical roadblocks.
Likewise, meet your product owners frequently if they aren’t already embedded in your team. At the end of the day, they will be the ones selling and maintaining what you made. They have to believe in the solution as much — if not more than — you do! At the very least, ask upfront how involved they want (or don’t want) to be. Even a quick written or verbal update of “here’s what we’ve done”, or “can we clarify something?” will go a long way to reassure them and give them an opportunity to share ideas.
However, once you get to the “build phase” where you are coding or prototyping in earnest, it’s best to have only your core team in the room. My suggestion: schedule a reoccurring meeting with your product owners and advisors once a week for 30 minutes in the research phase. Change that to bi-weekly or monthly once you enter the build phase. In our case:
(month 1 = research phase), (month 2 + 3 = build phase)
Ground work is important, but so are hard stop dates for each phase of your project. Spend too much time in meetings rather than making and you’ll find yourself behind schedule.
02: How to Navigate Being the Sole Designer…
…or Developer, or Data Scientist, or Product Owner
In month 2, we began building the solution. As the only designer, I needed to work fast. Our back-end developers and data scientist could set up repositories without me, but our front-end developers couldn’t start without my designs. So, where to begin? In short, share the burden where you can, be transparent where you can’t.
Being a team of six, we each were solely responsible or dually responsible for our own piece of the project. On the positive side, that means we had a diverse set of skills and knowledge available to solve the problem. Yet, our biggest barrier was born from that same diversity. Since we don’t share the same knowledge base, it made communicating technical concepts and tools time consuming and confusing. It is a language barrier of sorts.
Think of it this way: we all come from different technical backgrounds, so we we don’t “speak the same language”. Being an expert in one field typically means you know very little about other fields. So, we needed to understand the basic grammar of each others disciplines before we could begin to understand each other. To ease this, we each taught each other about our disciplines to grow our collective fluency.
For instance, I knew nothing about artificial intelligence (AI) or Python when the project began, but after several AI courses I at least understood the basics. I also wasn’t shy about pausing a meeting to clarify something, no matter how silly or simple it seemed. Likewise, I spent time teaching my team mates about design by giving them links to design thinking courses, and running a hands-on workshop. I explain how below, but if you are a non-designer, feel free to skip this next section!
Designer Specific Tips:
Your team mates may have little to no experience even working with designers, that doesn’t mean the can’t help! My suggestion: bring your team in to the design process early to help you with early ideation and to ensure everyone is on board with the design. To accomplish this I created a half-day workshop. I taught wire framing basics and created a low-fidelity storyboard with the whole team. The final solution was rudimentary all told. But! It got everyones ideas out of their heads and on to paper to discuss.
I was lucky to have a team interested in learning UI and UX, and they embraced the process, but not everyone will be so agreeable. To help reduce any resistance you may face, here are some steps and resources to get you started:
Step 1: Group Activity
Teach them the basics of low-fidelity wireframes including common symbols and shorthands. If they’re eager try teaching user flows. (10–15min).Step 2: Individual Activity
Set a timer and facilitate Big Idea Vignettes or Crazy 8’s. Aim for 8 distinct ideas — or 8 variations of an idea — per person. (30min)Step 3: Individual Activity
Take your favourite idea and flesh it out in more detail with storyboarding. A single 3–5 step storyboard per person is plenty. Each person should present their idea to the group. (8min for storyboarding, 1–2 min per presenter).Step 4: Group Activity
Take all the storyboards and stitch together a single, unified storyboard. Feel free to edit or add steps as you go. Prioritize the phrase “yes, and…” over “no, but…” during discussion. If your team is having trouble deciding democratically, try silent dot voting. (10–30min).After this initial workshop, you likely won’t need to design directly with your team anymore. Still, continue to share your work and ask for critique from your team to prevent misalignment down the line. As always, cost justifies usability!
03: Don’t Be Humble
(about your final outcomes, at least)
Being humble is a virtue, they say, but the final month of your project is not the time to be humble! The work you’ve done for the project up until this point has likely taken dedication and effort, so don’t down play it!
To be honest, it’s something our team struggled with each time we presented our progress to IBM executives. We were so close to the project, it was hard for us to see what achieved each month. We only saw the flaws and features we weren’t able to build, while everyone else only saw the potential of what we already built. On the flip side, I’ve also had projects where I’ve experienced the exact opposite problem! Being too confident or too humble can be detrimental to how your audience perceives your project. Either way, this is how we dragged ourselves out of the habit:
First, do a test run of your final pitch or presentation early with people you trust. Bonus points if at least one of your volunteer(s) has little to no context. All of them need to be someone who isn’t afraid to be honest, no matter how brutal. Pick someone who will push you to make the best presentation you can, and don’t settle for the first presentation you came up with. The goal here is to: 1) practise in front of a live audience, and 2) gauge the presentations overall persuasiveness. Our product owners and Professor Ameyot filled this role for us.
Secondly, give your team 24–72 hours to implement any changes based on their feedback. Don’t spend too much time polishing the presentation before then. There were times we had to completely re-do the presentation. So, if we had presented to our volunteers the morning the real presentation was scheduled, we’d never have enough time. This means you’ll likely be presenting an unpolished draft, and that’s absolutely okay! As a perfectionist myself, it was hard at first, but showing a draft makes it easier to receive honest critique. If it looks like you put effort and time into making an infographic or a pixel perfect chart, they may feel too bad to tell you to scrap it entirely. You also may have a hard time tossing out a bad presentation because of the effort you put in — but you can’t polish a turd! If the content doesn’t communicate clearly, it doesn’t matter how beautiful it is.
Final note: why is it preferable at least one volunteer has “little to no context”? Be mindful that your audience wasn’t in the meeting room with you the whole time. This means you need to create a logical narrative for them to follow or else they won’t buy your solution. Someone unfamiliar with the project will pinpoint logical errors or irrelevant information. However, keep in mind who your real audience will be and pick an equal stand-in. If your audience is technical, like engineers or CTO’s, pick a similarly knowledgeable colleague. On the other hand, if your audience is non-technical, pick a parent or friend with little technical knowledge.
Final Thoughts
If you made it to the end, thanks so much! I hope this article will give you a little guidance on your own journey.
Interested in joining Area 631 yourself? It’s open to current employees of IBM and university interns. Look for 4-month and 16-month job postings in August, December, or May.
And reach out if you have any questions @ breanne.r.lewis@gmail.com!
Breanne Lewis is a UX and Content Designer based out of Vancouver, Canada. The above article is personal and does not necessarily represent IBM’s positions, strategies, or opinions.
