Participants:
- Craig Nishizaki, Head of Business @UpTop
- Michael Woo, Head of Design @UpTop
Length: 3m 26s
How do you handle unrealistic client timelines? Michael Woo and Craig Nishizaki share strategies like educating clients on realistic timeframes, assessing project readiness, and emphasizing the need for clear requirements. Learn how alignment and communication ensure success—or when to walk away.
Transcript:
Michael Woo:
So let me ask you, how do you push back when asked to deliver faster than it’s realistically able to?
Craig Nishizaki:
So, great question. And again, I think for us, as we were going through the discovery and scoping process, there’s these checkpoints or things that we push back on. And ultimately if the client doesn’t align with this, then that’s when we walk away. And so to go through the process of trying to educate them and push back, we provide relevant examples of work and the timeframes that those products take to design, develop, and commercialize for context to their situation. So they can see we’ve done it before. From that experience, we can tell you here’s how long it should take, and here’s the effort and the budget and the timeframe. We educate them on the process that it takes for a product to be successful in its development and commercialization. And oftentimes that’s because we may be talking to somebody that’s on the product side that isn’t as technical or doesn’t have as much experience with the design process.
Or you may be talking to someone on the business side that doesn’t understand some of those has some blind spots as well. Or you might be talking to someone on the technical side that may have some blind spots. And so educating them the whole process is part of what we do to help educate them and then asking them for fundamental pieces that they should have in place at the point they are in the product development process. So do you have your problem statement? Do you have your product vision defined? Do you have the personas, the roles, use cases and tasks all documented? Do you have your user requirements, your business requirements, your functional requirements? Do you have the technical architecture? Have you already started building out your list to prioritize features that we can then craft into the roadmap? Do you have the roadmap already in place?
And then do you have the workflows, the user flows, and the wireframes already sussed out? And based on what they have in place, we can then assess the level of effort to get to where they need to be for them to be successful. And I think the big lesson though is that I would always say is you can’t expect to get a fixed scope, timeframe and budget with loose requirements. There’s two sides to the relationship of building out the product. And if you don’t have the requirements defined the vision, defined the work done, then there’s no way to have any predictability in a fixed scope timeframe or budget. And the reality is everyone wants predictability in a plan. They want to know that when they commit budget to this project, that it’ll get done within high certainty, within that budget, within that timeframe and within that quality expectation that they have.
Michael Woo:
Yeah, that is so true. I’m glad you said that, and I hear you say that all the time, and I think folks need to actually read it back to themselves or really listen to those words because when things are ambiguous as they are, I don’t know how you could put a price tag on that, right?
Craig Nishizaki:
Absolutely.
Michael Woo:
Time.
Craig Nishizaki:
Yeah. It leads to mutual mystification. One group thinks they’re doing this, the other group thinks they’re doing this, and ultimately that leads to a bad result.
For more information, watch the entire podcast which includes the clip above.
