A useful software engineering practice is to work on the hardest part of a program first. If you can't complete that piece then you'll never be able to get the full system to work. For example, if a program has 10 components, and component #10 is the most challenging one, then coding up #1 through #9 first means that an engineer might waste a lot of time before figuring out that the entire project is impossible. It's more sensible to start with #10 to understand if the project is viable in the first place. Tackling the easy stuff first is basically procrastination.
The Lean Startup approach is very similar to this engineering practice: instead of building a full-featured product upfront, you talk with prospective customers and build an MVP quickly to see if an idea merits more significant investment. While it's easier and more fun to start writing code, that's a recipe for disaster.
Pitches often dodge the hard parts instead of facing them head on. When trying convince others to invest in a product or a startup or a VC fund, a lot of presenters will give dismissive or shallow answers to tough questions. That's a tempting thing to do, but it's rarely the right move. Here are some concrete examples:
Investor: What is your competitive advantage?
Founder: We execute better and have more domain expertise than other companies in our space.
(Almost every competitor will say the exact same thing.)
Founder: We're trying to raise $1m, but have investment offers that total $5m. Why should we take your money over another investor's?
VC: We add more value than other funds, and our partners have deep operational expertise.
(Most VC funds claim something similar, so this is basically a non-answer.)
Prospect: My business can't risk downtime. How do I know your product will be up 100% of the time?
Salesperson: We've been live for 10 weeks and haven't crashed yet! We don't expect that to change anytime soon.
(An anecdotal response that doesn't really address the prospect's concern.)
During startup pitches, I like to ask a lot of questions. Some of the questions are hard — in fact, sometimes I don't even know what a good answer would look like. The worst replies are dismissive. For example, "Google would never compete with us because it's not in their DNA" or "we're going to win because our tech team is better than everyone else's." I'd much rather hear "I don't know" than a dismissive answer. The best replies are well thought out and compelling. They might turn out to be wrong in the future, or I might disagree with them in the present, but they demonstrate deep thinking and conviction.
For instance, many founders will say that Google wouldn't compete with them because it's too focused on a few core moneymakers like Search. That's BS. Google obviously values search, but it has also shown a strong willingness to build products ranging from office suites to self-driving cars. On the other hand, a founder might say that Google wouldn't be a strong competitor for a specific product because the product requires doing integrations with a lot of partner companies, and Google historically has not been great at that. (Google likes to do most things in-house, and a lot of companies are wary of working with Google since the company eventually competes with some of its partners.) I think that's a much more thoughtful and meaningful answer.
Why do people dodge the hard stuff? Often, it's because they're afraid of facing it. What if Google could (and would) copy your idea successfully? What if you're not building the right product? What if your CTO isn't a strong enough technical leader? What if you don't stand out when compared to other VCs? What if you can't make your product's key algorithm code performant enough? Ignoring or dismissing these questions is a mistake. Just because you're afraid your CTO is weak doesn't mean you can sweep that under the rug and see what happens.
If a customer or an investor or a founder asks you a tough question — or if there's a tough question you've asked yourself — don't be afraid. Think about it. Really think about it. Answer it to the best of your ability. If you can't come up with a good answer, think about it some more. Get advice from others. Run experiments. Do whatever you have to do to come up with a strong response. If you can't, maybe that does mean your product idea is not defensible, or you're not building the right thing, or you need a new CTO, or you don't have what it takes to be a great investor, or the program you're working on is impossible to code up. These things are not pleasant to find out, but neither is wasting years of your life working on something that's hopeless. Why waste time on the easy parts if you know you won't be able to finish the hard parts later on?