This is the story of a startup called Phaidra, who makes an advanced A.I. that helps industrial plants save huge amounts on their energy bills. Last year my VC firm Character invested in Phaidra, then ran Design Sprints to help them find product-market fit. Today, Phaidra is announcing a $25M Series A. So this post is a bit of a brag because I’m stoked that the sprints worked and I’m proud as heck of the Phaidra team. But more than anything, I hope this behind-the-scenes case study might be useful to anyone who’d like to use Design Sprints for product-market fit.

I’ve led a lot of Design Sprints over the years and I always have a great time, but this sprint with Phaidra stands out as one of the really special ones. There are a few reasons:

1. An exceptional team
2. An exceptionally difficult problem
3. A happy ending with product-market fit

But I should chill out on the Cliff’s notes and just tell you the story. Check it out:

The backstory: From Google to factory floor

Two of the founders, Jim Gao and Veda Panneershelvam, are world-class artificial intelligence experts. They used to work together at Google’s DeepMind. (If you haven’t heard of DeepMind, it’s the real deal — basically the 1996 Chicago Bulls of A.I.)

During their time at DeepMind, Jim and Veda ran some of the coolest projects there, including the A.I. that beat a world champion at Go and the A.I. that reduced Google’s data center energy costs by 40%. Jim and Veda began thinking about starting their own company, and they were particularly intrigued by the success of that data center project. Where else could A.I. save huge amounts of energy?

Industrial manufacturing.

Factories and industrial plants use tons of electricity on heating and cooling and operating all kinds of equipment. The more they thought about it, the more Jim and Veda became convinced that they could radically improve industrial performance. Building the A.I. would be really hard, but Jim and Veda had built impossible things at DeepMind.

However, writing amazing code wouldn’t be enough. Every factory and industrial plant has different machinery cranking out different products. It’s a much messier landscape than the tightly-designed Google data centers Jim and Veda were familiar with. They needed a legit industrial expert — someone with the expertise to help them figure out technical challenges and the credibility to build relationships with customers.

Enter Katie Hoffman. Katie had worked on engineering and innovation at Ingersoll Rand, Trane, and Raytheon. She’d spent years in a hard hat. She knew industrial manufacturing inside and out. And she was just as excited and optimistic about the potential for A.I. as Veda and Jim.

So together, the three of them founded Phaidra. Jim’s the CEO, Veda the CTO, and Katie the COO. Now they just had to build the product.

A quick side story

Around the same time that Phaidra was forming, we were starting our venture fund, Character. I say “we” but the truth is the whole idea was cooked up by my co-founders John Zeratsky and Eli Blee-Goldman. The first I heard of it was on a phone call with John, which went more or less like this:

JZ: “So I’ve got this idea to start a venture fund based on Design Sprints.”

Me: “What do you know about running a venture fund?”

JZ: “Dude, don’t forget we worked at Google Ventures for all those years.”

Me: “Yeah but we weren’t running it. I didn’t hardly know what was going on. Plus, where are you going to get all the money? Plus, how are you going to convince top-tier founders to go with a VC they’ve never heard of?”

JZ: “Well, I was paying attention at GV. Also, my co-founder Eli knows everything about venture capital and he’s kind of a genius. We’ve figured out how to raise the money. And I’ve already started prototyping the idea by talking to founders. I’m telling you, it’s going to work.”

Me: “Um, do you need another co-founder?”

JZ: “Maybe.”

A few months after this conversation, the fund was launched, and John called me up and told me everything you’ve read above about Phaidra. He also told me he wanted to invest in Phaidra’s Seed round, making them the very first investment in our portfolio. I was stoked. And when I found out that Phaidra wanted to do a Design Sprint, I got even more excited. I’m a sci-fi nerd, and I remembered reading those DeepMind stories and feeling like the future was pretty cool. Now I’d get to work with those guys!

Okay, back to the real story:

The missing piece

In our next conversation with the Phaidra founders, Katie described the company’s biggest, most pressing challenge. In a nutshell, she said, “It doesn’t matter how good the technology is if our customers don’t understand it or trust it.”

Here was the situation: Jim and Veda were having great success building the back-end tech that could learn how any given industrial system worked and make minute-by-minute adjustments to improve efficiency. But Katie saw a problem: If the engineers who ran the plant didn’t trust Phaidra, they might shut it off. It wasn’t enough for Phaidra’s A.I. to work — the human operators needed to know why it worked.

These workers were right to be skeptical — they are experts, after all, and most things marketed as “artificial intelligence” these days aren’t especially intelligent. Phaidra needed to build an interface that could help the A.I. explain and prove itself. If they couldn’t create this missing piece, they couldn’t win over new customers and their brilliant technology wouldn’t matter. That’s where the Design Sprint came in.

Zero to simulation in five days

The Design Sprint was five days long. The team included all three Phaidra founders, plus a designer, a software engineer, and two colleagues from customer-facing technical experts. Katie was the Decider — as the person in charge of the project, she would make all key decisions in the sprint.

Now I’m gonna take you inside the Design Sprint. Get ready for a lot of images and nitty gritty details. You can skim if you want, of course, but if you’re running a startup yourself, or just nerdy like me, maybe you’ll dig it:

Monday

On the first day, the team made a high-level map of how this new software interface would work for various customer types:

Katie identified the key questions we needed to address:

1. Would people understand and trust what Phaidra was doing?
2. Could the software demonstrate the business value of Phaidra’s artificial intelligence?

At the end of the day, Katie chose a target. The most important customer type, she decided, were energy management engineers who were responsible for the cooling systems in their facilities. And the most crucial moment for those engineers was checking the stability of their systems to make sure Phaidra’s A.I. was prepared for upcoming changes — and wasn’t doing anything wacky.

From there, the rest of the week’s plan was clear. The team would recruit a few energy management engineers from different factories and plants for a test on Friday. And we would spend Tuesday and Wednesday figuring out what that “stability check” should look like and how it should work, then create a realistic prototype on Thursday, just in time to show the engineers.

Tuesday

The team sketched competing proposals for how the “stability” interface might look:

Wednesday

The team reviewed the proposed solutions and had some structured arguments using Miro.

Next, Katie chose the approach she believed would work best for engineers:

Then we created a storyboard — a kind of blueprint for the prototype we would build the next day:

Thursday

Now the team had just one day to build a prototype. Following the storyboard, Mandi (Phaidra’s design lead) built this in Figma:

The prototype would test all of Katie’s key questions about product/market fit:

Friday

On Friday morning, the Phaidra team was ready with a realistic simulation of what the interface could look like. Throughout the day, they tested the prototype with four industrial plant engineers on four separate Zoom calls.

The results were mixed, but promising:

Take a look at those top two questions — those were the keys to product/market fit that Katie identified on day one. It appeared that the “Time Machine” solution was good enough to establish trust with engineers. The team could’ve switched out of Design Sprint mode and started building this new front-end.

But Katie, Veda, Jim, and the rest of the team looked at the scoreboard and didn’t want to stop. They already had hunches about how to close the gaps on those yellows and reds.

Design Sprint 2

So they followed up the next week, sketched new solutions based on their improved intuition, and Katie chose a new approach for their second iteration:

Then the team turned the “Inspector General” into a new and improved prototype:

Finally, they tested with four different engineers. Here’s how the scoreboard changed from sprint 1 to sprint 2:

Now, Katie and the team had momentum and confidence in the solution. As Katie put it: “We accelerated 3–4 months of product progress into 5 days. More importantly, we de-risked our product by testing with real customers.”

They switched into execution mode and started building the “Inspector General”.

Outcome: The Inspector General rides on

Today, Phaidra’s artificial intelligence works as well as Jim and Veda first guessed it would — or maybe even better. So far, Phaidra’s A.I. reduces energy usage at their customers’ factories and industrial plants by 15 to 30%, and does it while going easier on the equipment — which means fewer breakdowns and other headaches for the facility teams to deal with.

As for the console and building trust with customers? The “Inspector General” sketch is now real live software:

The other cool thing is how this UI is helping Phaidra pitch and close deals with customers.

Remember, the second key question Katie picked during the Design Sprint was “could the software demonstrate the value of Phaidra’s artificial intelligence?” The answer is a big fat YES. The team uses screenshots and live demos of the front-end in their marketing and sales process to show the value of Phaidra in a concrete way.

The other secret reason we run Design Sprints

Here’s a secret: we don’t just run Design Sprints with our portfolio companies because we want to improve their chances of success. I mean, first and foremost, yeah, that’s why we do it, and we think it’s great, obviously.

But we have another sneaky motivation as investors: In a Design Sprint, we get to see the team in action, and understand the risks and potential of their business, in a way that most investors don’t get to do.

This is huge. In these two sprints, we spent more than 40 hours with the Phaidra team, and saw customers react to their product live. So when Katie, Jim, and Veda asked if we wanted to invest more in their Series A, it was a totally easy decision. The team is even more awesome than we thought, and we’re even more excited about the product now that we’ve seen inside. So we tripled our investment as part of their new round of funding.

One last ramble from Jake

Design Sprints help teams gain confidence in their own solution, and that’s exactly what happened here with Phaidra — they started the sprints with more questions than answers, and ended with clarity about what they need to build to be successful with customers.

But in parallel, each sprint is helping us at Character to build confidence in our solution for our customers, who are startup founders. We’ve run many sprints since this one with Phaidra, but Phaidra was our first investment at Character and our first full Design Sprint with a portfolio company. We’ve got this crazy idea that a venture fund based on Design Sprints can work, and each successful sprint gives us more confidence that it will.

For me, this whole thing was really fun to see. On one hand, sure, I’m confident about Design Sprints. Like I said, I’ve led a lot of them. I now expect that two back-to-back sprints will usually get a strong team from zero to on-track, and I’m used to watching key questions flip from red to green as the team learns and hones their intuition. Hey, if we didn’t believe Design Sprints help teams find product/market fit, we’d have no place starting a venture fund on the premise. I should be confident, right?

But on the other hand, there were a lot of reasons to feel nervous at the start of this sprint. Our first sprint as Character. A hardcore computer science problem in an unfamiliar context. Brilliant founders on a mission to transform multiple industries… and here’s me, an art school dropout, ready to waste a week of everyone’s lives. It could’ve gone wrong in so many ways, so it’s pretty rad that the magic worked.

This startup used design to make industrial A.I. trustworthy to humans was originally published in Sprint Stories on Medium, where people are continuing the conversation by highlighting and responding to this story.

And I was like, huh. Yeah. I guess that’s true.

I thought about my own experience. I don’t like nonfiction books. That’s a weird thing to say, considering I’ve written a business book and a self-help book, but I don’t just totally love the genre. I’d much rather read fantasy or sci-fi, and usually I do.

But if I think back on the work-related books I’ve bought over the years, it’s been a pretty killer investment. Even though I didn’t read most of the books I bought! Like I said, I’m way more into fiction. And I’m lazy. Anyway…

I did some math on the business books I’ve read over the last ten years, just roughly making up most of the numbers. I probably bought 120 books over that span, costing roughly $2,400 (and 216 hours of reading time, figuring I read 10% cover-to-cover, skimmed 60%, and didn’t read 30% of the books I bought which is sad but true).

$2,400 is a lot of money. However, I got a lot of really valuable ideas and skills from those books.

Here’s one example: Made to Stick by Chip and Dan Heath. I bought and read the book in 2007 (okay I know that’s more than 10 years ago whatever). Made to Stick made me at least 20% better at telling stories, maybe more. Turns out storytelling was everywhere in my career for the last ten years! I used ideas from that book in hundreds of presentations and most things I write. (Not counting this post which I just wrote super fast—don’t judge Made to Stick by my hack job!)

It’s impossible to quantify exactly what that skill was worth to me. But it is definitely safe to say, really extremely super conservatively, that over ten years it was worth enough to pay for all the other books.

That’s good, because to tell the truth, most of the books weren’t worth anything. But a few were really really valuable.

Those nonfiction business-y books were like really tiny, low-risk, high-reward investments. Before I bought the books, I couldn’t tell the valuable ones from the worthless ones. Sometimes I didn’t even know after I read them… it might take a few years for the value of a concept to really emerge. But wow, those valuable ones, like Made to Stick, were SUPER valuable. And there was a risk they would be worthless, sure… but at most I only lost $20 + 1 hour (I never bother reading a book cover-to-cover if I’m not way into it, and neither should you).

It’s funny because it often feels like I don’t have time or energy for books because I read so much online. There are soooo many posts (like this one) and they’re free and really easy to access, so they can displace books. But how often do I learn a game-changing concept from a post? Pretty much never. I’m so much more likely to get something good from a book.

When you buy a book, you get a condensed and synthesized download of somebody’s brain. For about $20. Sure, it might turn out to be a brain you don’t need, but if it is—wow! What a bargain!

Okay I’m pretty done with writing this post but I have a few more quick things to say in summary, etc:

1. Books are cheap.
2. Especially if you consider how much time and work goes into making them! Jeez!
3. Free stuff on the web (like this) seems like a good deal, but if it displaces reading books (it totally does) it’s actually expensive because your time is limited.
4. If you buy a book and it isn’t interesting to you, don’t give yourself a hard time about it. It’s just a low-cost high-risk investment that didn’t pan out. Give it away or sell it and move on… but keep buying books.
5. By the way I am financially invested in you buying books so you shouldn’t trust me! Hahahaha!

💸📚

This summer I got to do a super fun project, and I thought I’d write it up. It started several months ago, when I got an email from Laura Prah, who leads culture and engagement at The New York Times.

Among other things, Laura is in charge of an event at The Times called Maker Week. Maker Week is like a hackathon. For one week every summer, folks are encouraged to step away from their regular work (as much as humanly possible at a newspaper) and experiment with new projects. They start on Monday, and on Friday they share prototypes with the company.

Laura was considering integrating the design sprint into Maker Week and she wondered what I thought. Well… I was stoked. I mean, first of all, it was The New York Times! I figured if I played my cards right, they might even invite me to visit. (Spoiler: this actually happened!)

Second, the design sprint seemed like a good fit for Maker Week. The design sprint is a step-by-step process for starting new projects — a sort of recipe for team problem-solving. In a design sprint, the team creates competing solutions, decides on the best, then builds and tests realistic prototypes, all within a single week. It was quite easy to imagine overlaying the design sprint steps over the top of what The Times was already doing.

And there was one more reason I was excited. This idea of a “Maker Week Remix” offered a chance to tinker with the traditional hackathon, which is a format I both love and hate.

Hackathons are the best and the worst

Hackathons are awesome because they offer protected time, an artificial deadline and an experimental mindset that can stick in the team culture long after the event is over. In fact, hackathons were one of my inspirations when I created the design sprint (back in 2010 while I was at Google).

But hackathons are also not awesome. Without a clear game plan, newly-formed teams can waste time and lose their way. Many hackathon projects go nowhere when the event is over. And people often exhaust themselves working super long hours — as Jason Fried noted, you might be better off with a sleepathon than a hackathon.

By combining design sprints with Maker Week, Laura and I figured we might highlight the good stuff in hackathons while fixing some of the trouble spots.

Design sprints typically have five to seven people, but Maker Week would have 65. So I had to “scale up” the design sprint to work with several teams at once. I had a few ideas, because for the last year, I’ve been running design sprint workshops that often have 100 or more people. But those workshops use a “canned” project so that every team is working on the same fictional challenge. Multiple teams working on multiple real projects is much more complex, so I was a bit stressed out.

Six tips for design sprints with multiple teams

In the end, it worked out even better than I hoped. If you’d like to run a similar large-scale event with lots of teams, try making these six modifications to the normal design sprint process — they really helped me.

Emcee instead of facilitate

1 The design sprint is intended for one small team with one facilitator leading them through a checklist of activities. For Maker Week, I had 13 teams all together in one big room. There was no way I could rotate and coach each of the teams, so instead, I treated it like a big workshop (or yoga class) with me at the front talking everyone through the steps.

Step-by-step slides

2 With so many people, I needed more than verbal instructions. I’ve developed a slide deck for my training workshops, and I adapted those slides for Maker Week. With them, I had a visual cue to go along with each step. This helped teams move super fast and stay focused.

Condensed schedule

3 Normally, the design sprint process takes five days. On Monday, the team creates a map of the problem and chooses a target; on Tuesday, they sketch solutions; on Wednesday, they decide which solutions are best; on Thursday, they prototype; and on Friday, they test the prototype with customers. But — knowing that not every team could take all five days off — Laura and I decided to compress Map, Sketch and Decide into just two days.

To tell the truth, I was apprehensive about getting all these different teams through the condensed schedule. I put together this spreadsheet to plan the activities minute by minute, adjusting the times as we went:

Use modified map and storyboard tactics

4For Maker Week, I used the checklist from my book Sprint along with two improved techniques: the Note-n-Map (from Stéph Cruchon in Switzerland) and Storyboarding 2.0 (from AJ&Smart in Berlin). These techniques provide extra structure for the mapping and storyboarding activities, which normally require a lot of hands-on facilitation. Both worked like a charm. Even though they didn’t have dedicated facilitators, the Maker Week teams quickly created maps and storyboards without a lot of discussion.

Roving helpers

5 I brought my buddies Jonathan and Luke to roam around and help if teams were confused about a specific step. As a bonus, Jonathan — who has run more design sprints than I have — watched the energy level of the room and helped me figure out when to speed up and when to slow down.

Music to keep the peace

6Many of the activities in the design sprint require silence, but it’s hard to enforce silence with 65 people in the room. And once one group starts murmuring, the broken focus quickly spreads. So I played some ambient music to remind people when to stay quiet and focused. (My playlist includes instrumental music by Marconi Union, Jamie xx, the Beastie Boys, Kamasi Washington, Chromatics, Dave Brubeck, Daft Punk, and others — and I used this tiny bluetooth speaker which projected sound throughout the space remarkably well.)

From zero to prototype in two days

Remember how I was nervous about squeezing three days into just two? Well, at 2 p.m. on the second day the teams were already finished with three days worth of work! So we moved on to what is normally the fourth day of the design sprint: prototyping.

From 2 p.m. to 5 p.m., the teams put their heads down and cranked out their prototypes. Then, at 5 p.m., we shared progress. This was amazing: almost every team was finished with their prototype. They had done just 15 hours of work (seven and a half on day one, seven and a half on day two) and they were already done with what normally takes all of Maker Week.

I think there are a few reasons why the teams were able to sprint and prototype so quickly. First of all, because the hackathon projects were all new or speculative, there wasn’t a lot of background knowledge to share or politics to work out. Part of what takes time during the map step of a design sprint is working through the messy details of real, long-term projects. For better or worse, a hackathon environment avoids those details and starts with less information — so day one was a breeze.

The projects were also fairly well scoped. Laura and her colleagues Kelci Shipley and Jody Mak had supplied each team with a “How Might We?” question to seed their design sprints (for example, “How might we allow subscribers to engage directly with editors?” or “How might we allow users to track the physical delivery of their paper?”). These questions had been carefully phrased to keep the scope appropriate to Maker Week.

It also helped that the people in the room knew the app, website and editorial tools inside and out. I’m used to working with startups, who might try to define a brand and a marketing plan and a technology stack all at once. The New York Times has been around for 167 years (really) and they’ve had a website for about 142 years (not really, but it seems like it). There’s already a strong foundation and many components to work with, so when it came time to build the prototype the teams could really fly.

Finally, and I think this is important, everybody came in with the right mindset. In a design sprint, part of the facilitator’s challenge is to help a team move quickly, forget about being perfect and get into an experimental mode. Maybe it’s because Maker Week is already an institution at The Times, or maybe it’s because the digital team is used to quickly experimenting with new ideas and technologies.

A better hackathon — but still a hackathon

In the end, even a design sprint-ified Maker Week was still a hackathon. The projects were all explorations — answers to questions that the Times is curious about, but perhaps not quite ready to act on. When the dust settled, everybody went back to their real work and had to catch up. Most teams didn’t test their prototypes with target customers, and most didn’t plan to take their prototypes anywhere.

Normally this would absolutely kill me. I hate it when the projects go nowhere. I crafted every step in the design sprint to be pragmatic, each one making progress toward building something real.

And yet… fundamentally and intentionally, the Maker Week projects are short-lived experiments that are never intended to see the light of day. Laura was explicit about this from the very beginning: Sending new projects to production is not the goal. Instead, Maker Week is about practicing exploration.

So I’ll add one more suggestion for multi-team sprints:

Set clear expectations: Launch vs. practice

7 Decide in advance whether the goal is launching or practicing. And be honest, because it’s very hard to keep hackathon projects alive, and very frustrating to be told something has a chance to launch only to watch it go nowhere. If you decide to make it practice, do what Laura did and be very clear at the beginning, and remind people over and over: This is practice. The point is to flex our experimentation muscles.

It’ll take some time to know if the design sprint-ified Maker Week was a success, but I have a good feeling about it. With a little luck, The New York Times will use design sprints on more real projects (they already started last year) and… who knows, maybe one of the Maker Week experiments will defy the plan and catch on? Either way, it was good practice.

If you try a large-scale design sprint/hackathon at your company, let me know how it goes!

Photos by Jonathan Courtney and Luke Knapp

Want to learn more about Maker Week? Check out these posts:

Maker Week Roundup — Homegrown Product Development at The New York Times

Maker Week: 5 Days of Collaboration and Innovation at The New York Times

How to Run 13 Design Sprints at Once: Inside Maker Week at The New York Times was originally published in NYT Open on Medium, where people are continuing the conversation by highlighting and responding to this story.

Me? You should be skeptical of my advice—I’m a solid designer, but not amazing, and I’ve actively avoided being a manager. I don’t hire people. What do I know? But I have gotten a few design jobs over the years. Here’s my advice.

1. Pick one project. JUST ONE!

What’s the coolest thing you’ve worked on? Doesn’t matter if it wasn’t really that cool (the coolest project in my first portfolio was the portfolio itself). I define “cool” as “interesting”. Not the prettiest. Not the famous-est. What was the most interesting thing you’ve worked on? Which project do you understand best from start to finish?

That’s your project. Forget everything else. It’s okay if your portfolio only has one focal point. You’ll learn enough from crafting this one story that you’ll become more articulate about the other projects.

But really you only need one. If you have an hour to present your portfolio, or an hour in an interview, one deep well-told project can get you there.

Okay, got the one project in mind? Let’s go.

2. Squeeze out the best possible story

Now figure out how to tell the best possible story about that project. I’m not just saying put images of your process and some obligatory text. I mean tell a damn story. I want a hero’s journey with five acts. I’m not even joking—I want you to build some mystery and suspense.

Write it down on paper first. Jot down notes about the storyline of the project. I mean like if the project was a movie or a mystery, what was the plot?

“We wanted to x for our customers/we thought y was a really cool opportunity… but we didn’t know how to do it or if it was possible…”

Okay, now I’m interested! Introduce the characters:

“I was the lead designer, working closely with a product manager and an engineer. The three of us had this crazy idea…”

How did you get there?

“We each sketched… we disagreed about… we decided to test… we needed to find out, so we…”

Tell it like a great story, you know? Keep up the mystery, make it human, make it simple. In the end, what happened? What did you learn? Was it a success? No, it wasn’t. Nothing is completely a success, so what did you learn from the parts that failed? What did you learn from the nasty parts of the process? What would you do differently next time?

3. Find images to support the points in your story

This is obvious because it’s a design portfolio, duh, of course you’ll have images. There’s one thing though—above all else, collect images to tell the story. Sure, make it look good, make it look like you’re a good designer, yada yada. But if some of the images suck and the story is great, that’s better than a nondescript good-looking design portfolio. Tell the story! As you look for images, you may be reminded of different twists and turns in the plot, and if they’re good, add them to your notes.

4. Practice telling the story out loud

Nope, not time to build the portfolio yet. Just put them in Keynote or Powerpoint. Flip through the images and tell the story. Ideally, you should present it — to your boss or colleague or team at work, at a meet up, at a conference if you can, but whatever. Find a place to present it and do it. The stress of presenting will make you practice and master the story better.

You should be able to make your story interesting to somebody who is not in design or technology — somebody who is not remotely in your line of work. You should have friends like that—if you don’t, stop reading this stupid post and make some—and they should be your target audience, not some imaginary design expert. Learn to tell your story in plain language, without jargon or acronyms. Learn to tell it without the images. Learn to make it compelling, and, if possible, funny.

Read Made to Stick. It isn’t about design or products or business — it’s about telling memorable stories. And, as it turns out, that’s what design and products and business are all about, as it turns out. And that’s what you are to your potential new team. You’re a story. You better make it interesting.

5. Tell the same story over and over and over again

Practice at work. Practice with your friends. Practice with a significant other. Telling a story to a person who just heard it yesterday is harder than telling it to a stranger. It’s high altitude training.

Practice by yourself, saying it out loud. Giving a presentation to one person is harder than giving it to an audience. I’ve spent sooo many hours giving presentations to myself. It’s awkward but every time is one more repetition. Every time you learn. The more times you tell the story, the better it gets, and the better you get. Tell it, tell it, tell it.

Here’s the secret: You are developing the skill of synthesizing work into a narrative about why and what matters. You are leveling up. The story isn’t a trick to make yourself look better—the story is the way to be better.

6. Lastly, make your portfolio

Once you’ve got the story simplified and crisp and great, turn it into a web page or a blog post so people can view it even if you aren’t there. How should you do it? I dunno, and I don’t really care, but you better do your homework and do a good job. It seems to matter.

Read the posts at the top of the page. Look at other portfolios. Run some web searches and pick good ones… I’m not here to tell you what everybody else is gonna tell you better. I will say that if you make your portfolio site work like a slide deck, with a tight narrative… that’s probably not a terrible idea. Worked for me.

I will say you should consider including a video/screencast of you telling the story. You made your story totally kickass by now, right? It’s your secret weapon, so feature that bad boy.

7. Make it pretty

Haha! That headline is partly here just to make all you designers mad. But it’s also true: “Make it pretty” should be the last thing you do. Your portfolio should look good. It should demonstrate that you care about craftsmanship and detail and you’ve got the skills to deliver quality. But for god’s sake, don’t start there.

That’s all I got

If you do these things, you’ll have totally mastered one story and figured out the “why” and “how” behind your key project. You’ll understand the business side, the product side, and the people side. You’ll have crafted a product, in fact, out of the story itself. You’ll be better prepared as an interviewee, and you’ll have a portfolio piece that (hopefully) stands out from the rest.

I can’t guarantee this approach will work. It’s what I did, and it got me jobs when I wasn’t qualified—which was true for any job I ever got, at Oakley, Microsoft, Google, or Google Ventures, or when I pitched the Sprint book to my agents. But telling a good story always helped. With a story, a portfolio hangs together.

If you’re curious, here’s a video of me telling a story about a sprint (the story is at 27 minutes). This is a story I’ve told a million times, so it’s very simplified, but maybe you’ll see what I mean about the what and how and why and everything.