Suhail Doshi

Suhail Doshi quotes on problem Solving

Founder MightyApp + Mixpanel. Pizzatarian, programmer, & music maker.

Twitter wisdom in your inbox

Never miss the the top tweets from Suhail Doshi with our email digest.


Founders: we need the best engineers to work on our hardest problems! Engineers: I want to work on AI, interesting hardware problems, and scaling! Reality: hey, so can you make a landing page, make forgot about password, and fix these 3 bugs customers are complaining about?


Making great products isn't about adding more, more, more. It's often about discovering a single great problem and working to refine, refine, refine.


Two important vectors to build momentum in a startup are listening to users & shipping speed. To listen well, you'll need to constantly talk to users & be picky about who to serve. To ship quickly, you have to scope just enough & have good instincts about how to solve the problem


Every startup has a few seemingly impossible walls they hit: it could be churn, a deep technological limitation, a seasonality problem, no market upmarket, rising user acquisition costs, a new giant competitor, political regulation, or worse. It’s your boss battle to win.


Startups are basically a competition to figure out how to solve problems in less than a month that popular belief suggests will take an enormous set of resources or time. Death looms so one must earn momentum & traction in order to keep solving the next set of hard problems.


A big part of being a great engineer is the difference between "Ok, it works & I am done!" and "it works, I fixed the most common edge cases, I'm aware of more UX issues but lets put 'em in the backlog for now, lets ship—i know there's more work to make this great"


It’s okay to launch your app with only a handful of invited users. Don’t let anyone pressure you into scaling because they think you’re being elitist—making a few people happy is critical at the beginning. When the product is great & everyone is using it, that noise won’t matter.


There are two major parts of engineering: (1) challenging problems that require research, trial & error, and flashes of insight to accomplish and (2) raw hours of grinding to get something done & you know exactly how to build it. Both are often required to build something great.


On ideas: "Why hasn't anyone done that?" is one of the best ways to kill the momentum of a fragile idea. "Has anyone done that idea really well?" is a better way to contribute & make it stronger.


All startups constantly go through waves of uncertainty ranging from does anyone want this to how will we make money from all these users? What I’ve found helpful is focusing on 1 problem at a time & commensurately doubling my focus on each sub problem as I go. This is all normal


The biggest threat to product delays, receiving feedback too late, & seeing if ideas have any legs in the real world is having the discipline to ship a small, well done version of the bigger thing you’re working on & just seeing what happens to minimize confounding variables.


The happiest moments of starting a company, for me, have often been (1) having no clue how to solve some challenge, (2) the momentary feeling of uncertainty/death if we don't solve it, & (3) the solution being discovered together with a few smart people. Have faith.


The easiest way I've found to motivate myself through the trough of sorrow is to just ask: Are all my problems solvable but don't require miracles? If the answer is yes, I just keep grinding.


Doing another startup has retaught me the lesson that once you know precisely what users care about (answering more complex questions, better battery life, etc.), that continuous, relentless focus on attacking the problem can get you further than you or others initially imagined.


Most people strive to be first to market but another clever approach is being intentionally *delayed* to market. You let a few companies form, validate what the demand is like, discover big gaps unsolved, and you narrowly solve a different big problem vs the most competitive one.


As your team grows, every founder that sweats the details will often feel compelled to jump in to offer feedback or help quickly solve a problem. It's been my experience that you should resist that urge at first because you'll learn what you're missing in the team that you value.


One of the best parts I've had starting a company is in the first 12 months: you go from a casual observer of an industry or technology to understanding just how far the boundaries have been pushed to date. Then, you graduate into being forced to find a new way to bend things.


There are just some months where your startup needs to solve one singular problem to make almost all your users happy to break past the next barrier for growth. So turn off all the dashboards, focus the team, put your head down, and get it done.


The most complicated problems are made less overwhelming by breaking them into discrete sub-problems, assigning teams with a clear goal, & having patience. If you don't have the resources to solve all the sub-problems, partner & focus on a narrower set.


The great advantage of starting a company that has hard technical challenges is it’s much easier to attract the best talent later. The disadvantage is most people probably think you’re going to fail early on so it requires a great leap of faith from the first 5 people.


Most startup technical debt largely occurs as a function of "Let's do X and call it a day" because there's about 20 other stomach-churning reasons your company will probably die that need to be addressed first.


Startups have these sweet moments where you step into a challenge, you have no idea how you're going to solve it, & you spend days/weeks trying everything you can. Then, a few clues & insights from helpful people create a solution. And all you want to do is a cartwheel after 🤸‍♂️


Every startup in the world has an incredulous moment where their viability is at risk due something inefficient but solvable due to licensing, pricing, archaic laws, or artificially limited tech. It’s still, however, a good filter amongst founders that are resourceful or aren’t.


For many products, getting your users to delete the alternative, incumbent product is the final moment you know you've made it with that user. Products often cannot merely reach parity, they must be a lot better. I like to ask: "What would it take for you to delete <y>?"


I hope with more programmers, more funding, and more competition to build the same mobile/web app, that it will move the momentum for great engineers to work on harder problems previously seen as too risky due to longer time horizons. Being easily copied might be higher risk now.

Get the top tweets via email

Never miss the the top tweets from Suhail Doshi with our email digest.

Get the Suhail Doshi email digest

Twitter wisdom in your inbox