> If you’re planning on spending two months improving the revenue created by feature X by 3%, do the napkin math to see if existing revenue coming from X justifies two months salary.
How do you know they didn’t? That deck is just a summary of years of work. Perhaps reach out to Dan McKinley for further discussion. I’m afraid we’ve both just making a lot of speculation at this point. Talk to Dan.
When your revenue is 7-8 digits, 3% can add up! Sometimes it’s such a no-brainer that it’s not worth opening Excel over. Last week I had my devs spend a few days implementing a way to create DHL labels using an API. We didn’t do any cost-benefit analysis because it was so clearly something that needed to be done. Today we shipped 147 packages by DHL. That would have taken about 5m each to do the old manual way, so in one day it saved 9.5 hours of staff time. Over one-year that’s an entire salary.
But I think the presentation tells you why they weren’t doing that stuff:
And you know what, if the site’s growth is really insane, it looks like it’s working. You can release things and as long as they don’t completely destroy everything it will look like you’re a genius. All the graphs will go up and to the right.
You can read in the Farnum St. interview with Tobias Lutke, CEO at Shopify, how it held back Shopify’s growth. I’ve met Tobias and he’s a brilliant, level-headed engineer and CEO, but if you read that you’d probably conclude he’s irrational, stupid, and not ambitious enough for not relentlessly maximizing growth for that period. ¯\_(ツ)_/¯
Regarding testing and validation, of course there are exceptions, but generally speaking, it still looks like they got it backwards to me. You’re free to disagree. I’m running multiple companies and have produced many products and services—only one big failure. I’ve tried a lot of approaches and still mix and match many ideas, but can solidly endorse making the prototype in get the feedback.
Maybe you misunderstand how we think about prototyping. A realistic façade is all you need to test with customers. The prototype give you something concrete to put in front of customers for rich feedback and insights. But think lightweight (dirty) version of key aspects of a product or experience. The prototype only needs to be good enough to test out a hypothesis and nothing more. It’s all about testing big ideas with minimal upfront investment.
I recommend the design thinking methodology presented in “Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days.” Invented at Google by Jake Knapp, perfected with more than 150 startups at Google Ventuer (GV).
> If you’re planning on spending two months improving the revenue created by feature X by 3%, do the napkin math to see if existing revenue coming from X justifies two months salary.
How do you know they didn’t? That deck is just a summary of years of work. Perhaps reach out to Dan McKinley for further discussion. I’m afraid we’ve both just making a lot of speculation at this point. Talk to Dan.
When your revenue is 7-8 digits, 3% can add up! Sometimes it’s such a no-brainer that it’s not worth opening Excel over. Last week I had my devs spend a few days implementing a way to create DHL labels using an API. We didn’t do any cost-benefit analysis because it was so clearly something that needed to be done. Today we shipped 147 packages by DHL. That would have taken about 5m each to do the old manual way, so in one day it saved 9.5 hours of staff time. Over one-year that’s an entire salary.
But I think the presentation tells you why they weren’t doing that stuff:
You can read in the Farnum St. interview with Tobias Lutke, CEO at Shopify, how it held back Shopify’s growth. I’ve met Tobias and he’s a brilliant, level-headed engineer and CEO, but if you read that you’d probably conclude he’s irrational, stupid, and not ambitious enough for not relentlessly maximizing growth for that period. ¯\_(ツ)_/¯
Regarding testing and validation, of course there are exceptions, but generally speaking, it still looks like they got it backwards to me. You’re free to disagree. I’m running multiple companies and have produced many products and services—only one big failure. I’ve tried a lot of approaches and still mix and match many ideas, but can solidly endorse making the prototype in get the feedback.
Maybe you misunderstand how we think about prototyping. A realistic façade is all you need to test with customers. The prototype give you something concrete to put in front of customers for rich feedback and insights. But think lightweight (dirty) version of key aspects of a product or experience. The prototype only needs to be good enough to test out a hypothesis and nothing more. It’s all about testing big ideas with minimal upfront investment.
I recommend the design thinking methodology presented in “Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days.” Invented at Google by Jake Knapp, perfected with more than 150 startups at Google Ventuer (GV).
Prototype comes before Test.
https://www.thesprintbook.com/how
Cheers,