Suhail Doshi

Suhail Doshi quotes on product

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.


In year one you likely don’t need: - A fancy office - A full-time assistant - An office / ops mgr - 2000+ sqft of office space - Fancy furniture - Lots of employees (> 10) - Perfect design What you do need: A product people love in spite of its flaws. The rest will come.


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.


Speed is a near universal value in most startups: speed to ship, speed of initial ux, speed of the app loading, speed of decision making, speed of hiring or firing, speed of customer support. Speed is your best defense while you have no moat.


One of the earliest signs your product is getting better for users is that your job steadily shifts from building all day to doing customer support all day.


People underestimate how much grit it takes for founders to steadily build the most monotonous features in order to make an okay product great. Especially difficult when there are so many more interesting/intellectually challenging v1 ideas to distract you.


I’ve learned to never underestimate the power of 100 little improvements that could be potentially boring to build & unsexy compared to one, large net-new risky feature. Over a long run, those 100 little things make companies appear far more innovative & make a huge impact.


Me: Ok, I am going to put this software through the wringer to find reproducible bugs to fix. Bugs: Nah, not coming out. Taking a nap. <later> Me with users: Ok, thanks for signing up. Now, just click the icon & it should "just work." Bugs: WHAT'S UP FAM. HOW WE DOING TODAY!


The best way I've thought of to make a startup more formidable and narrowly focused is to tell them what I'd do if I were their faux competitor. The ruthless perspective of a competitor often helps sharpen what's important & what's not. So, ask your smart friend what they'd do.


I’ve been doing a lot of interviewing of engineers lately & the biggest defining difference between great ones and decent ones has mostly been whether there’s a natural, innate curiosity of how things work. Then, a desire to dive down the rabbit hole to seek the true answer.


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"


One of my early mistakes in the 1st two years of building a co was building new products because users seemed happy. That lack of focus put us back a year. It's usually a mistake to expand to a new mkt because the product is "done" for the primary one but your mkt share is < 1%.


Increasing the surface area of a product is the most subtle way companies move slower. That’s why it’s so important to be clear on what you’re willing to be great at & willing to cede to avoid the debt incurred by more features. So, experiment quickly & ruthlessly deprecate.


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.


A big part of starting a company is being very optimistic about its very possibility, persistently banging your against a wall until you figure out how to make each part work, and then finally doing The Great Merge where you glue all the pieces together to make a working product.


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.


Trying to make a 1000 people happy by chasing primarily the macro-set of issues among them all is a surefire way to make a mediocre product. A different approach is trying to make 10 people really happy then finding 990 people just like them.


One tell-tale sign things are starting to go well in a startup is when you finally have users using the product more than you do. Particularly when the product is something you want too.


Products make platforms. Platforms sustain product longevity.


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.


Stages of building the 1st product: "Is this possible?" "Anyone care about my prototype?" "I have 50 things missing I need to build" "Why is growth flat?" "omg things are getting better" "I have 50 bugs I need to fix" "Finally gonna add all the things I wanted in v1" <Long delay>


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.


Most projects that are 70% done are not released because they aren’t perfect yet. However, if you edited down what you have to its very essence, you’d probably stand to gain 90% of the impact if you just released that to the world.


10 happy, evangelical paying users are worth more than 100 semi-satisfied paying users.


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>?"


Early versions of products have a rapidly growing backlog as soon as you get through the previous one. Once the product starts nearing the minimum set of features to satisfy one narrow use-case, a new minimum set forms around a different but overlapping set of use-cases.


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.


It is really understated how significant of a productivity gain you can get by having a workflow where you can make the smallest change combined with the fastest feedback loop to see its impact. Maybe that’s why WYSIWYGs will continue to be such a valuable thing for the world.

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