Interview Practice: Maintaining Quality on a Tight Deadline

The question, sourced from a pre-interview assessment:

How have you maintained the quality of your work when on a tight deadline?

At first blush, this question felt tough. So many of my projects have been on tight deadlines, but I don't recall specifically needing to sacrifice quality for progress. The trick is: no matter the deadline, my process didn't actually change, it was my communication around expectations that did.

Every project started with a question (well, more than one - but this is the relevant one):

What's the most important thing for us to get right?

If we can get on the same page about what we really need to be focused on, it's clear where we can spend less time and maybe circle back to when we can. This communication was a gamechanger for me in making sure that I'm spending the bulk of my time where it matters - and where our stakeholders expect to see gold.

Then, once those expectations are clear and in writing, I figure out how we can build it as lean as possible. What does the true minimum viable product (MVP) look like? Where do we have play in what we can deliver, so that we do deliver meets or exceeds our standards? I like to look at the Lean Startup methodology for inspiration here.

Here's how this has played out for me:

Earlier this year, I got pulled into a project to build an urgently needed MVP on a very tight deadline. They needed the designs yesterday and it was holding up other teams' work. There was a lot of pressure to just get in and start designing without context.

Day one, I organized a kick-off call with our stakeholders and a separate one with our users with the sole goal of understanding what success looked like for this iteration of this project. I asked questions like:

To be considered a success, what does this MVP do? What does it not?

At the end of the quarter, what do we want stakeholders to report about this MVP?

I sketched a plan with realistic deadlines for what I believed we would get to, with a worst and best case scenario. I visualized which features or functions were in our stretch goals, versus which ones were non-negotiable.

After walking through that plan with the team and confirming that, yes, we were prioritizing the right things, I got to work.

My task was to digitize a workflow that was happening entirely in excel sheets and on antiquated software. In a day and a half, I sketched three really rough designs for what that workflow could look like as functional (but somewhat bare) prototypes and had my users walk through them.

None of the prototypes sparked joy immediately, but my users could pinpoint the aspects they liked and what they felt was missing. The real magic was that this process led to them showing me a part of their workflow that hadn't been relevant during discovery - but was very relevant to *how* they liked to work.

I took the best parts of all three prototypes and settled the entire thing into the layout they had shared with me during testing. Within three days, we had something we knew users were happy with that we could share with the rest of the product team to determine level of effort and identify any technical constraints.

I've always been a fan of the Lean methodologies, but this was an instance where it helped us accomplish what I don't think would have been possible otherwise. We created, on an extremely tight deadline, a product that served our users beyond their expectations and fulfilled the needs of our stakeholders in all of the areas that were most important to them. On top of all that, we also had a plan for how we would continue to improve, once all of the urgent work had been completed.