Design Sprints have spread far and wide from their original development at startups and have become a ubiquitous practice on a global scale at a wide range of organizations. It’s a good bet that any designer reading this probably already knows what they are, much like the way all engineers are familiar with the basic principles of agile development.

“A five-day process for answering critical business questions through design, prototyping, and testing ideas with customers.”

But now that it’s been a few years, it’s worth asking: do design sprints work? And if not, then what are alternative collaboration techniques?

Before we dive deeper, let me say up front that I’m not against design sprints, agile development, lean startups, or any other business practices. Different techniques will work for different teams and situations.

All kinds of factors can explain why your mileage will vary on any advice, so try different techniques and see what works well for you.


History & Format

A design sprint is a week-long exercise for teams to create and test realistic-looking prototypes, saving the time and engineering effort it would take developers to build the ideas for real.

Each day has a different focus and set of exercises:

It was initially used internally within Google on various products, before then spinning out to Google Ventures and applied to their portfolio of startups.

Inspired By Agile

Although designers have worked within a sprint format on engineering-centric teams for a long time, what popularized the term is the particular format created by Google Ventures and their subsequent book documenting the process.

Design sprints have a few similarities to the agile version for developers:

  • Work is highly atomized and structured.
  • Projects are timeboxed to less than a week.
  • The focus is on action and working prototypes, not research and planning.
  • High amount of interdisciplinary collaboration.

It's easy to see why the practice would be friendly to large engineering-heavy teams or smaller fast companies, given the spiritual kinship to the already ubiquitous practice of agile development.


People Love It

Design sprints have clear upsides and it’s easy to see why the practice has such widespread appeal. It’s simple to learn, emphasizes collaboration, and uses testable prototypes to shortcut engineering overhead, all within a specific timeframe.

It's become a worldwide phenomenon and you can see the palpable enthusiasm from people trying it for the first time:

Ditches UX Dogma

It's fun to shortcut engineering overhead and jump straight into action. Design sprints upend decades of UX dogma and skip past research techniques that add unnecessary overhead for questionable benefits.

From Jonathan Courtney’s article User Research is Overrated:

Up-front user research is a form of product procrastination. It’s busy-work, it’s a way to avoid making hard decisions. It delays the need to make something tangible.


It took a while, but eventually […] we figured out that even though it was nice to “have the user in mind” when designing, the useful data came from the first user tests, not the research.

User interviews, focus groups, personas, empathy maps, mindmapping, ethnographic field studies… it’s all a bit much. Especially if you’re not in a large corporate environment and trying to sell the value of a project before it even starts.

In the last few years, “UX research” has quickly become synonymous with “enterprise red tape” and the explosion of startups will only add to the effect. Although there might always be large companies with rigid hierarchies, the trend is definitely towards smaller and quicker teams that just get down to business.

You don’t have to skip the research, you can use sprints in combination with traditional UX techniques if you get value out of them and have the bandwidth.

But for a lot of people, pseudoscientific research isn’t the work you signed up to do. You’re not in some anthropology class about technology, you’re an action-oriented type that just wants to make cool and useful stuff.

Compared to the previous 20 years of UX dogma, it’s just a much more natural approach to brainstorm up ideas, sketch out a few, and then test out some prototypes on prospective users.

Teaches Leadership Skills

On top of sprints being easy to learn and focused on action, I can also see how they can act as a communication bootcamp for introverts and new grads.

Teaching leadership skills is absolutely vital. It’s critical for designers to lead teams proactively, rather than reactively create whatever’s dictated to them.

Whether you like it or not, being a designer is a leadership role because design sets the standard for product quality and user delight for the entire organization.

And leadership means independent thought, not just collaboration — using your own critical thinking skills to work through problems and potential solutions. Otherwise you’re doing what the H.I.P.P.O. says and just another cog in the groupthink machine. acronym for the Highest Paid Person’s Opinion, which can have an outsized influence on group decision-making when left unchecked.

So hell yeah, I love anything that shines the spotlight on a designer for a week and encourages the kind of leadership skills that set the tone for the entire team.

Another thing they don’t teach you in design school is what you get paid for…

Mostly, designers get paid to negotiate the difficult terrain of individual egos, expectations, tastes, and aspirations of various individuals in an organization or corporation, against business needs, and constraints of the marketplace…

Getting a large, diverse group of people to agree on a single new methodology for all of their corporate communications means the designer has to be a strategist, psychiatrist, diplomat, showman, and even a Svengali. The complicated process is worth money. That’s what clients pay for.

Rules Are Necessary For Learning

Also, a prescriptive approach is really helpful for students and designers earlier in the career. The enthusiasm is palpable in conversations on Twitter and popular forums like Designers Guild on Facebook.

The simple rules of a sprint are definitely more approachable compared to other schools of thought in the design world — e.g. the vague and hand wavy principles of design thinking, or the research-centric and documentation-oriented techniques of enterprise UX.

A well-documented process is fantastic for those in the initial skill acquisition phase of their career. You need clear rules and guidelines the most when you're first learning your craft.

That's one of the key takeaways of the Dreyfuss model of skill acquisition, which outlines the typical developmental stages someone goes through when progressing from student to master, at which point they'll rely more on intuition and need greater autonomy.

If you’re interested in reading more about smart techniques for sharpening your thinking skills as you progress in your career, then I highly recommend the book Pragmatic Thinking & Learning. It changed my life and I gained habits that have become second nature in the years since.

On a personal note, I was no different early on — I loved rules too. Fervently.

When I was starting out, I so dogmatic about following Jakob Nielsen’s advice that my best man gave a usability-themed speech at my wedding. I ate up anything I could about usability, HCI, UX and design. I saved up every penny of the education budget at my first job to attend the workshops by Adaptive Path, the pioneering design consultancy. Their all-star founders shaped the nascent UX field and gave clear guidelines for rookies like me.

The kind of heuristic techniques you learn from rules are invaluable for getting up and running in a competitive field, which explains a large part of the appeal of design sprints and their basic format.

Big Companies Crave Process

In addition to being accessible to new designers, a clearly defined and regimented format is a natural fit for larger organizations that prioritize steady dependable results over the fits and starts of smaller startups.

You know the kind of places I’m talking about — the ones that use corporate buzzwords like “innovation” without a hint of irony.

Not all large organizations are badly run, obviously. LEGO has a fantastic case study about how they scaled design sprints throughout their company and it's a fascinating read.

But all too often, a newly popular and clearly defined process can turn into inflexible and tedious dogma. Given the hunger in the corporate world for the latest business trend, it’s no wonder the initial blog posts and books for starry-eyed newbies have expanded into a small constellation of workshops and conferences. There's even certification courses for facilitators!

Who knows, maybe design sprints will be just like countless business fads before it that went supernova and then experienced gravitational collapse down to a background radiation level of influence.

Or maybe it’ll grow ever larger and calcify into the kind of thing taught in business schools. I’m sure there’s still a handful of gasbags somewhere that brag about being scrum masters, right?


Wrapping up the impact of design sprints on the field, there’s a lot of positives to like about it. Overall, a design sprint sounds like a fun game with clear rules and an approachable way to demystify creative work by turning it into a repeatable process, while also encouraging concrete user insights, communication and independent thought for rookie designers.

It all adds up to a compelling package and I can see why it's had such a wide uptake across a broad audience, from action-oriented scrappy startups to process-loving large companies and agencies.


My Initial Reaction

Still, as fun as design sprints sound, I remember being a bit surprised when design sprints first started to get popular. I remember thinking, doesn’t everyone know this stuff already?

I’m not saying good design is universal these days, just that the principles for tackling those challenges seem pretty well documented.

It’s not like design sprints are bringing awareness to new techniques like when the UX field was first starting up, so design sprints sounded to me like they were just an agile-flavored remix of typical best practices: group brainstorming, usability tests, quick prototypes, etc. Basic stuff taught in any school or bootcamp these days, and also very easy to pick up for self-taught types.

In fact, I should be exactly the target audience for this: a designer from a technical background that’s comfortable with agile techniques and early stage companies. Doing the full-stack of design with fast engineers at startups is my jam. So is doing user research on the fly and without making a big production out of it.

Being a designer at an early stage company is particularly challenging and takes a specific kind of attitude, whether learned or acquired. An army of one that doesn’t mind being outnumbered by engineers and business types.

I’ll check out anything that’s down with the cause of making design faster and comes from the helter skelter world of startups.

So I looked past my initial reaction and dug into it a bit more. After all, it’s an admirable goal to help designers be more nimble and execution-oriented.

But without getting into the age-old debate on the drawbacks of agile, reading up on the rigid schedule and emphasis on collaboration over expertise rubbed me the wrong way and made me see why my spidey sense had gone off. It made me think of a paraphrased version of the old saying about regular expressions:

Some designers struggle to keep up with developers and think “I know, I’ll make my design process more like engineering.”

Now you’ve got two problems.

Well more like a handful problems, when I get into specifics in the section on drawbacks.


Ok, so if you’re not already super experienced as a designer or technical enough to be familiar with potential drawbacks of agile development, design sprints still sound great. Actually they sound kind of fun — a whole week to collaborate with your colleagues in new ways and learn various thought-provoking design exercises. So who wouldn’t like that?

Well, it turns out that I'm not alone in having reservations.

I am utterly and completely tired of anyone who claims to have a one size fits all design process to solve all problems. It’s lazy, misleading, and a sign of an inexperienced designer who can’t objectively choose the right process for the current problem.

And the critics aren’t limited to just people that I know personally, like my friend Ian. When I read articles like Erika Hall’s “Design Sprints Are Snake Oil” and Invision’s “When A Design Sprint Isn’t The Answer”, that’s when I decided to document my doubts in a more detailed way and explain my startup-centric view of the practice.

I’m sure every process has its detractors because it doesn't work in every situation, so that’s to be expected and perfectly normal. I thought at first that maybe my qualms were because of the type of teams that I’m used to — super scrappy early stage startups with absolutely no time to spare — but pinging others made me realize that it might be a wider problem and not just an individual preference or work situation.

After all, if I’m not the only one seeing downsides to this trend and sprints won’t work in every situation, then there’s a need for people to learn about alternatives. So let’s get into the details of why a week-long sprint is a non-starter in many circumstances...

Selling Instead Of Doing

Various techniques will go in and out fashion over time, that’s just a natural part of any industry. However, there’s one universal constant about them all: there’s what a methodology says it’ll do on the packaging and what its actual purpose is.

For example, it’s a recurring joke that agile development isn’t always very agile. Extremely regimented and formal versions of the process make a development team anything but quick and nimble.

Yet that’s for a good reason, since agile is really about expectation management for stakeholders and avoiding executive randomization of engineering pipelines, not making developers faster.

Similarly, design sprints probably won’t produce the absolute best design work because it’s not about making designers better. There’s a larger meta goal instead: stakeholder buy-in. You can say it’s about teamwork but whatever you call it, the exercise is meant to build respect for designers so that they have the time it takes do more informed work.

So let’s get real — design sprints are about getting buy-in from stakeholders by teaching design basics.

Buy-in for common best practices is useful. It’s a smart idea to teach overall principles of the discipline to stakeholders and engineers so that they’ll understand the time and research it actually takes to cook up decent work. Hopefully they’ll also see the true cost of rushed and reactive work that doesn’t address underlying UX issues.

However, a week is a long time to take off just for subtle power dynamics. Even if your company isn’t in constant survival mode, you should be able to establish solid design principles without completely pausing the product pipeline and asking everyone to learn arcane techniques.

I get that design is fun and everyone’s got an opinion about it, but can you imagine doing this for every role in the company? Taking a week off to learn sales techniques, then another one for customer support triaging, then yet another for leadership, then a bootcamp for picking the next engineering stack…

Come on, let’s get real. That sounds like a course about workplaces, not an actual workplace. At some point, you have to trust that everyone will just do their damn jobs.

All of this means you should temper your expectations about the actual design work that will come out at the other end of a design sprint. You probably won’t emerge from one of these things with a shiny new design that’ll save the business, for example. Because it's not the point — getting your boss enthused about your field is the real aim.

Again, these are admirable goals but the week-long format is not a fit for a lot of teams, ones with pressing and business-critical needs, with stakeholders that trust the expertise of their hires, and with designers that already know when to use the right tools and in self-sufficient ways that don’t slow everyone down.

Startups Don’t Have Time

And neither does anyone else, really.

It might be ironic to complain about design sprints taking too long when it claims to reduce months of dawdling to a single focused week, but even a entire week is too long to waste in my experience.

Time — and the lack of it — is the main reason I’ve become accustomed to using a variety of techniques on an ad hoc basis. The types of high-pressure environments I’m used to can’t take off even just a few days from their usual work of developing and shipping features. It’s impossible for most startups to press pause for that long, no matter how dire their design debt.

Startups aren’t the only ones without time. A healthy sense of urgency is a major commonality between all productive teams and endless meetings is a pretty good sign of the opposite.

Years ago, after I moved to SF but before I went to my first startup, I worked at a mid-sized company that regularly hosted large meetings with dozens of people. I used to amuse myself by estimating how much money we were wasting by doing a little back of the napkin math. It always came out to thousands of dollars per hour! You can try it yourself with an online calculator for meeting costs.

That doesn’t mean small or fast teams never need meetings or a solid product direction. Actually, startups need design guidance the most, because otherwise you accidentally cook up an explosive cocktail; a frenetic pace of feature development doesn’t combine well with an early company poking around in the dark for product/market fit. Startups inevitably run into avoidable pot holes because of their overwhelming emphasis on maintaining momentum, even while in an exploratory mode to define their main purpose.

So how do you reconcile massive design needs with an utter lack of time?

The answer is not to cram a week’s worth of design activities into less time, it’s simply to use the right tools at the right time, as you go along.

Designing humane products and apps while having effective collaboration is not a one time fix — it’s part of the work culture for solid design-driven teams.

And especially when it comes to team exercises, you should be highly selective about only the few key tasks that yield the most benefit and make sure to space it out as much as possible, otherwise you’re wasting not just your time but everyone else’s as well.

Just to jump ahead and preview one of the alternatives that I’ll describe later, you can use a quick exercise like structured sketching to coax out the collective knowledge of a team in a single afternoon, without grinding an entire work week to a halt.

Most of the techniques in a design sprint are ones that a self-sufficient designer should be able to carry out in parallel, whether solo or by pairing up with devs and PMs, so why waste everybody’s time by exposing them to esoteric techniques?

Execution Trumps Strategy

The underlying reason why startups don’t have time is actually pretty rational and applies to most other company types too: staying busy is a survival mechanism. People try to stay busy shipping meaningful work, otherwise they risk stagnation at best and existential threats at worst.

One of the dirty secrets of business is that work is 90 percent execution. Success is less about inspiration or random strategizing than it is just plain getting shit done, day after day. Even at startups. Especially at startups, actually.

It doesn’t matter whether we’re talking about companies that are large or small, remote or co-located, ones with green logos or blue… The hard truth is that all truly effective teams are stocked full of high performing “armies of one” that use their energy to come up with and implement solutions, not to generate stunningly original ideas for work.

Everyone has ideas but real artists ship.

It makes sense, right? You can’t afford to have a company filled only with “visionary” types, daydreamers making academic arguments all day. You need people that can soldier on and learn by doing.

Yes, you need both modes of work — productivity and reflection — but that doesn’t mean equal amounts of time or a rigid schedule for each. Every person and team have to find their own rhythm and balance. Avoiding too much action without thought or thought without action is about team chemistry, personal challenges, and the interplay between them.

Plus anyway, it’s not like taking a break from the rigors of the usual execution-oriented work to host a strategy session is guaranteed to stimulate calm and reflective thought, peppered with smart conversation and interesting doodles that culminate in brilliant insights. Ha! If only.

In the real world, strategy sessions are usually the opposite of productivity. Sharpie showdowns at the whiteboard, going in circles with endless debates, all while losing momentum on shipping meaningful work. Meeting hell. Wasted time. Vacillating ad nauseam.

Good designers abhor vacillation and make teams faster, not drag them down.

Just even imagining taking an entire week off of shipping features gives me the heebie-jeebies. And don’t get me started on spending a day voting on features with post-its like grade schoolers assigning gold stars!

With all of my harping on speed, independence and most of all, high quality end results, I guess you could say that these are my version of Dieter Rams’ principles of good design, especially at startups.

A good designer knows how to:

  • Trawl through support requests to understand customer needs.
  • Interview stakeholders to distill business goals.
  • Do competitive analysis.
  • Make their own prototypes to test solutions.
  • Prioritize feature work.
  • And countless other things, without having to stop for guidance at every step.

Basically, try to work fast and independently.

And when it comes to group collaboration techniques, keep your powder dry and only gather the entire team when absolutely necessary and for the minimum time possible, to respect their colleagues’ time and energy.

Design Exercises Look Funny

While we’re at it, let’s also be real about how design exercises come across to most people.

Design exercises may have good intent but they look like pointless artsy vacillation to everyone else.

Stickies, whiteboard doodles, giant markers, weirdly scripted interactions that treat valuable customers like lab mice… they’re all insanely valuable tools that I love using. Hell, I’ve been running usability tests for two decades. The first book I bought with my first paycheck at my first gig out of college was Designing Web Usability, the Jakob Nielsen classic.

But I live in the real world and recognize that these techniques are completely unfamiliar and strangely childish for most non-designers, so they have to be used as needed on a project and definitely not all at once as a substitute for critical thought.

That’s why I usually assume everyone else is just too damn busy spinning their own plates to stop and want designers to just get on with doing their job, not to push the esoteric details of their internal methods on to everyone else.

It’s an absolute non-starter to ask most teams to pause their work for a week to play with kindergarten-style toys, just so you can figure out what the hell to work on and how to test its efficacy. It will get you laughed out of the room — as well it should!

You might as well turn down the lights, put on some crappy world music and scroll through random nature scenes while asking whether the end result should feel like a leopard or a butterfly.

What kind of hippie horseshit is this?!?

You Can’t Crowdsource Expertise

Playing with crayons and crowdsourcing product decisions by voting with post-its isn’t the best way to show design expertise anyway.

That’s not how to demonstrate authority. You’ll get respect if you respect other people’s challenges — their business needs, engineering constraints, customer support backlog, and a thousand other things — all without bringing the whole team to a stop.

Gaining respect comes from understanding everyone else’s needs, on the fly and under massive time pressures.

And most of all, respect comes from doing great work. You might not always get credit for nailing a design but guess who gets the blame if you throw every single idea into a blender and call it a group decision? Not the team or process. They’ll blame you, the designer. And rightly so — you’re supposed to be the arbiter of team input that distills down disparate needs into distinctly understandable visuals, not a hoarder that throws every idea into a junk drawer.

Good designs are hard decisions made visual — don’t shirk the responsibility under the guise of collaboration. Otherwise you’re no better than a PM or technical lead desperately cobbling together wireframes out of random design kits.

“Bad design gets out in the world not because the people working on it lack skills, but often because the decision-making process is broken. Fixing that is a team effort that has to go bottom up, top down, and all the way across.”

I don’t know why but so many designers suck at leading people. Getting your team to brainstorm up a few product ideas won't fix that core issue.

I can think of a few possible reasons that many designers struggle to lead teams:

  • Communication skills and independent thought are essential soft skills that are often overlooked in a typical curriculum.
  • Leadership can be more challenging to develop for some of the more introverted personality types that are attracted to aesthetic and creative expression.
  • Designers are defined in some quarters as more of a facilitator than a producer. They’re like artsy visual versions of project coordinators that emphasizes consensus and research, rather than strong product managers that sets vision and drive action.

That last point in particular bugs me because it seems so ingrained culturally, like a warped version of "the client is always right" that metastasized into "all of my non-designer colleagues have equally valid opinions on design as I do."

It’s a critical skill for designers to think for themselves amidst the pressure of being vastly outnumbered by other roles. The stakes are high. It’s about more than just doing good individual work, it’s setting the bar for expected product quality for everyone and avoiding the lowest common denominator outcomes.

Don’t just take my word for it, look at the science — there are research studies backing this up. Groupthink is the most common team dynamic and the results of groupthink are inferior to solitary thought by individuals.

So collaboration is great and all but that’s not the only thing you’re hired to do, to make sure everyone gets along no matter what. You’re there to make great products. You need to be strong, speak up and most of all, lead.


Be Fast & Flexible

I sprinkled some alternatives throughout the critiques and it’s worth recapping them all in one list. Here’s my overall principles of how to survive at startups and other demanding environments, all while doing good work and showing design leadership:

  • Use an “unprocess”. Pick the right tools at the right time and in a self-sufficient manner, rather than a regimented formal schedule. Think toolbox, not pipeline.
  • Keep up team momentum. Work 1-on–1 with various roles and bring the entire team together only in short bursts.
  • Understand everyone else’s needs rather than pushing design methods on other people to understand your goals. I.e. practice good user research skills within your own company.
  • Avoid groupthink. Don’t shirk hard decisions for the sake of consensus, or you’ll only agree on the lowest common denominator and make Frankenstein designs.

Think of this as my playbook for the kind of things designers ask about all the time: how to survive as a sole designer amongst engineers and earn the right to be at the decision-making table with business stakeholders.

Limit Team Meetings In Length & Frequency

Most of the various design exercises in a design sprint can be done individually by a designer, things like the creation of testable prototypes and gathering user insights, but there's obviously still going to be an occasional need to pull everyone into a room.

For team exercises in particular, I’ve found that the best format to bring everyone together is a long afternoon meeting, regardless of the particular topic or design exercise. It’s just long enough to get their best thinking, yet short enough to fit into an otherwise busy week.

Anything longer than the length of a movie is a corporate group therapy session disguised as real work.

There’s probably a biological reason why movies are all 90–120 minutes. It’s about how long you can expect a group of people to pay attention to a single topic before they have to get up to eat, use the restroom, or just get on with their day.

So it turns out to be the goldilocks amount for team meetings as well — not too short to rush through things, not too long to melt brains into uselessness.

E.g. for brainstorming, that’s just enough time to clear the air and vent any pent-up ideas before discussing more experimental solutions. For usability tests, it’s enough time to watch a session and discuss the lessons learned afterwards. So on and so forth.

And just like you wouldn’t try to squeeze in a movie every day at work, long team meetings shouldn’t be the norm or a standing meeting of any kind. That’s when organizational calcification starts to set it. Long meetings are just a good tool to have in your back pocket for when collaboration-centric topics have backed up and need airing out.

Practice Structured Sketching

Sometimes you really do need an all-hands meeting to crack a problem and tap into the collective wisdom of the team, yet you don’t want to fall into the usual pitfalls of brainstorming at a whiteboard: one large canvas for extroverts to dominate a conversation and solidify the groupthink in the name of consensus.

Effective brainstorming strikes a balance between individual thought and collective decisions. You want only the unique ideas that are stimulated by both processes — stimulating reflective thinking from every team member, as well as also synthesizing the best ideas into concrete product directions. It has to have a reflective individual component in order to avoid the conformity and confirmation bias innate to all groups.

To strike that balance, I like using a team exercise that I call "structured sketching". Originally called a "design studio", the format was a workshop that takes 1 to 2 days, which I modified and cut down to 90 minutes or less to get the same benefits. I wrote an article on the Zapier blog to explain the abbreviated format and documented the one we did at an off-site, but the gist of it is very simple:

  • Split a room full of people into teams of 3–4 and give them all sharpies and paper.
  • Pick a vexing problem or potential new feature currently on everyone’s minds, assigning one to each team.
  • Do timed rounds of drawing ideas, first individually and then as a group.

There’s a bit more detail — e.g. each round has a specific format — so check out the longer article for more info.


That pretty much covers my take on design sprints. I can see a lot of positives but for myself personally, I guess I’m skeptical of sticking to any one approach and taking off an entire week for a rigid format that makes an exciting workplace feel like I’m stuck in a remedial school.

I’m not saying I have all the answers, just that people should try something different if they’ve had similar reservations.

If you don’t and your team is down to try a design sprint, or you run them already and find it valuable, then that’s great! Don’t let me stop you. Rookies should have fun practicing their craft and learning new skills, and vets can use it to shake things up from the usual routine.

One thing I’d keep in mind before going into one of these: don’t worry about whether the deliverables are world changing or will fix all of your business needs in 5 days. Just think of it more as a team building exercise that indoctrinates the value of design and familiarizes everyone with the tools of the trade.

Teamwork is the ultimate end result of a design sprint because the team will still be there while various business trends come and go, so use whatever means necessary to wear all the different hats that designers are expected to be comfortable with.

On the other hand, if you’re a designer experiencing any of the problems I described about design sprints — if you find yourself chafing under rigid formats like I did with agile when I was starting out, if you like fast teams but all you want is better design input and don’t want the overhead of a dozen different exercises over the course of a week — you should probably experiment with other methods, techniques that are quicker and more flexible.

Try to mix things up a bit occasionally with things like structured sketching. Block out an afternoon once in a while (let’s say quarterly or so, whenever you feel like there’s pent up demand for brainstorming) and give the exercise a whirl instead to see how it works for you.

And most of all, just try to keep your head on straight. This job is hard but rewarding.


If you’ve actually made it this far, I can’t thank you enough for giving so much of your valuable attention, especially in this age of info overload and Twitter-sized witticisms. Trust me, I’m tickled by the irony of writing thousands of words on better ways to save time.

This article marks the relaunch of my blog and there are more long form essays in the pipeline about product design, UX/UI, startups and technology, so stay tuned for more!