Gmail wasn’t really a 20%-time project

I always thought gmail was an example of an employee coming up with an idea, and having automatic-permission to explore it due to Google’s 20% time.  It is constantly referenced in articles about the policy.

But there is some nuance here.  It turns out Larry Page asked Paul Buchheit to explore email:

Larry Page assigned the project to me. He said, “Build some kind of email something” and chose me because I had an interest in email. I tried to create a web-based email service in 1996, shortly before Hotmail, but didn’t complete it.

Interesting.  This takes away one powerful piece of evidence often used to justify policies that enable employees to pursue their own innovative ideas on company time.  In this case there was an executive sponsor right from the beginning.

Posted in Uncategorized | Leave a comment

Criteria for continued funding of new products

At Indeed we’ve been working on continually improving our processes for funding, staffing, executing and assessing new experimental products.

One of our challenges is assessing early products and figuring out whether to kill or continue them.  One approach used in the past has been ‘make-or-break’ goals.  This has typically been represented as a top line goal to reach at a point in time, such as: X hires, Y sales, etc.

Over time we have learned that these make-or-break goals do not provide enough flexibility for the product team and also do not provide enough flexibility for Indeed.  In certain circumstances the team might make the goal – but Indeed leadership is simply convinced that Indeed’s limited resources to test out new products should be spent elsewhere.  Conversely the team might not make the goal – but leadership is convinced that this was the wrong goal, and that further investment is warranted.  So we are no longer doing make-or-break goals.

What we are trying instead, is to use a metered-funding approach, where an investment committee provides funding in stages – and the project teams have autonomy to use their funding and pursue their vision, but when the money is running out they need to return to the investment committee for more funding.

So how does the investment committee decide if projects get further funding?  Here’s what I’ve been coaching Incubator teams with:

“For projects to continue they need to provide compelling evidence that is surprisingly positive that shows their product can produce sustainable value in a meaningful market.”

Let’s pick this apart:

  • Compelling Evidence – Bring verifiable data and evidence.  No evidence-based-learning means no more funding.
  • Surprisingly Positive – Sets the bar high, if there aren’t aspects of the experimental product that are working surprisingly well we should probably put our investments elsewhere.  Most projects will not find something surprisingly positive.
  • Sustainable Value – There is confidence that the product can achieve sustainability.  We don’t want to launch new products that are simply re-packaging our sponsored job advertising business into a different model and selling it for a loss.  Teams need to understand the cost of acquiring users, the cost of servicing them, and how these are trending.
  • Meaningful Market – We believe this market could be sizeable enough or strategic enough to be important to Indeed.

There is room for interpretation with these and over time we will provide more clarity and guidance, with examples.

By continually experimenting with a portfolio of new products, Indeed should be able to compare projects side-by-side, and invest more in the ones that better meet this criteria (and kill projects that fail to meet this criteria).


Posted in Uncategorized | Leave a comment

Seeds, Pods and Big Bets

Indeed is investing more and more in discovering and building new products.  As the product team discussed and evaluated our successes and failures – I found it difficult to communicate without some common terminology around the different types of innovation projects underway.

So here are a couple of terms I proposed that were intended to help the discussion.  In all cases I’m talking about trying to find new successful products – new sources of revenue that are pre product-market fit.  Initiatives to grow core business are outside of this discussion.

Seeds: Small projects; less than one quarter long; pursuing a solution to an opportunity; developing and piloting an MVP solution; gather some initial benchmark performance data.

Pods: Medium size projects; 3-4 quarters long; pursuing solutions to an opportunity; enough time to gather benchmark KPIs, to run some tests to see how the KPIs improve, and to try a few different approaches to the product.

Big Bets: Large projects; 6+ quarters long; strong commitment to a new business opportunity; try to launch and scale it quickly.

Projects of any size that have found product-market fit are no longer seeds, pods or big bets.  They’re new products and they need to be scaled as large and as efficiently as possible.  Also, these are not strictly stages.  These are different approaches to product discovery and development.


Seeds Pods Big Bets
Timeline 1 quarter 3-4 quarters 6-8 quarters
# of Engineers 1 engineer 2-3 engineers 3-5 engineers
Marketing Budget ~$15k $50k – $500k / qtr $250k – $2M / qtr
Purpose Pilot a specific solution to a specific problem.  Clarify an opportunity. Pursue a solution to a specific problem.  Some flexibility to pivot as the project proceeds. You believe you know the solution to a problem.  Go big and launch it.
Goals Go from zero to one. Quarterly goals.  A modest level of initial performance constrained by cost.  e.g. 10 hires at <$500/hire.  Improving significantly each quarter. Quarterly goals.  Showing growth, and performance improvement, constrained by cost.
Approvals Required None Senior Leadership approval Senior Leadership sponsor
Business Model Not established Establishing Should be clear


What are they good for?


Seeds are useful because they bring an idea to life.  It’s fine to research an idea – like creating a site dedicated to jobseeker events – but the requirement to actually pilot something adds a level of fidelity to it.  It’s way easier to engage with something tangible – to both poke holes in the idea, and to see the full potential.  Show, don’t tell.  The nice thing about seeds is that they don’t need Senior Leadership support.  You can – and should – support seed projects that few people would bet on.

Seeds also support the creation of pods and/or big bets.  Both pods and big bets are a substantial investment of limited resources (product, engineering, sales).  Starting with a seed is a way to get some clarity and hopefully some real data before committing to a pod or big bet.

You should expect to stop after the seed phase and then make a decision about what the next step is.  That might mean putting the seed idea on the shelf.  It might mean gathering the resources to create a pod.  But it’s a mistake to continue at the seed level too long.  They need more resources (engineering, marketing) to have much of a chance of real success.


Pods are like a small funded startup with a year of runway.  They have a problem identified, they are building and launching a product.  Their goal is to find product-market fit, or to show a clear trajectory on the KPIs towards product market fit – before the $ runs out.  Lean startup approaches to product discovery and validation apply here.

For pods to be successful they require a certain amount of investment.  They require 2-3 engineers.  They require product marketing support – with a budget.  They might require some integration with other products.  And they require some Senior Leadership support to help secure resources.

Big Bets

If you think you’re onto something, if you’re committed to it – then go big.  Pros: bigger product faster.  Cons: what if you don’t have product-market fit?  Then you’re burning lots of resources as you try to find it.

Big bets require an engaged executive sponsor because of the significant investment involved.

Ok, I understand the proposed terminology, so what?

Companies should be pursuing a mix of these concurrently.  They all have a role to play.   You should make it easy for entrepreneurs in the org to pursue a seed project they’re excited about.  This could be an innovation rotation, a labs/skunkworks project, or the permission to launch a nights-and-weekends project.

I would propose that pods are one of the most efficient ways to find product-market fit; enough resources to actually try something out and learn, but with limited cost to the company.

Finally – You shouldn’t be afraid to place a limited number big bets on the most promising opportunities in your space.  Bigger risks but bigger rewards.

Posted in Uncategorized | Leave a comment

Technical Risk vs Market Risk, Part II

Haters gonna hate.  Engineers gonna build.  Unsurprisingly, engineers are drawn to the challenges that interest them: reliability, scalability, and reduced technical risk.  In a product space where Market Risk dominates (see Part I), these are the wrong priorities.

A lot of startup advice makes sense when you realize it’s designed to address market risk not technical risk.  YCombinator basically exists to beat entrepreneurs over the head with this lesson – same thing with the Lean Startup methodology.

Even if you have a large amount of technical risk that needs to be addressed, don’t forget the market risk.

Consider the agile software development movement.  It began more than 20 years ago in the contract software development community, and was designed to address the high percentage of failed projects.  Since a lot of contract software development is for internal systems, there was an assumption of product-market fit embodied in the requirements.  However, all too often the resulting product failed to properly address the needs of the contracting organization.  It wasn’t that there was some technical invention missing – but rather that existing technology was shaped into a solution that failed to solve the problem.  The first principle behind the Agile Manifesto is:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

This addresses technical risk – ensuring subsystems work together as early as possible.  It also addresses market risk by providing regular checkpoints to validate product-market fit (even when there is someone writing a check who says they know what their organization needs).

But be careful!  Agile approaches don’t necessarily address product-market fit.  In a product company, building something in sprints doesn’t protect you from building the wrong thing in the right way.  If you aren’t validating the market as you go along (or better yet before), you’re just addressing technical risk (which is good, but not sufficient).

I was delighted the other day by an engineering manager who really demonstrated an understanding of technical risk vs market risk.  When discussing whether to put together an engineering team to start building a product – or use a more lightweight rapid-prototyping and piloting approach (that may need to be replaced if the product succeeds), the engineer manager said:

“I know we can build something that scales, what I don’t know is if the product will succeed”

That pretty much sums up most startups these days.  So spend more time finding out if the product will succeed and trust in your ability to scale.

Posted in Uncategorized | Leave a comment

Technical Risk vs Market Risk, Part I

If someone could build a teleportation device that worked, and that cost less than $2,000 to transport a person across the planet, they would be rich.

If someone were to build a bluetooth-controlled LED display that could be affixed to the back of a car and allow the driver to display messages from their phone, they might be rich.

What’s the difference between these two ideas?  In the first case, we know there’s a market for rapid transportation of people.  There’s evidence all around (cars, trains, airplanes).  What’s lacking is the technology – it’s not clear if the technology can be made to work.  In the second case we don’t know if there’s a market for communicating with the people behind you using your phone.  The gap is the market (or as some say, product-market fit) – it’s not clear if customers will adopt the product.

If you were thinking of investing in companies pursuing these two ideas, and you were talking about the risks, you would say the first has technical risk, and the second has market risk.

To figure out which kind of risk your product is facing, ask yourself: If the technology was available to buy off-the-shelf, cheap, and any startup could build it, would it be obviously successful?

  • High resolution mobile screen, with full web browsing capability (aka iPhone)?  Yes: tech risk.
  • Social network to share filtered photos (aka Instagram)?  No: market risk
  • Container that keeps vegetables fresh without losing any nutrients for a month? Yes: tech risk.
  • Macaroni & Cheese Flavored Ice Cream?  No: market risk

Interestingly, the rapid pace of technology has meant that more technology is available off-the-shelf (hardware and software), cheap and any startup can build it.  A lot of the lower hanging fruit of products with technical risk have been created; and new opportunities are now in reach. These new opportunities are for things that aren’t just better, faster, cheaper.  These are new opportunities to address unrealized needs; things you didn’t realize you would want or love.  I would put things like Twitter, Instagram, AirBnB, Pinterest and Snapchat in this category.  It wasn’t obvious that there was a market for these products.  And while they definitely had technical risk too, the bigger risk was market risk.

In the real world new products face a combination of technical risk and market risk.  But usually one dominates.  And I believe that we have moved into a world with more market risk than technical risk.  Take a look at the Unicorn List and ask yourself how many of these represent new technology that was risky, vs the application of technology into a new area with an uncertain market.

In part II I will show how this shift from technical risk to market risk explains the rise of Agile development and the Lean Startup movement.

Posted in Uncategorized | Leave a comment

Inside, what’s the culture really like these days?

I’m inclined to agree that the recent New York Times article on Amazon “Inside Amazon: Wrestling Big Ideas in a Bruising Workplace” appears pretty slanted and seems written to match a pre-conceived narrative.

I’ve never worked at Amazon, but I have former colleagues that I respect who work there.  A lot of the practices described in the article are much more benign in practice (e.g. systems for peer-feedback, meetings to calibrate the evaluation of employees, etc) and are pretty common among tech companies.

For those interested in these types of things, there’s a good counterpoint to the article written by Nick Ciubotariu, a current engineering manager at Amazon, here: An Amazonian’s response to “Inside Amazon: Wrestling Big Ideas in a Bruising Workplace”

However, Nick is writing from the perspective of a recent (18 mo tenure) engineering manager who is presumably very good at his job and well-suited to thrive.  Average performers, or folks in other departments such as warehousing, sales, marketing might have a very different experience.  Also, on occasion Nick has chosen his words very carefully, for example:

During my 18 months at Amazon, I’ve never worked a single weekend when I didn’t want to. No one tells me to work nights. No one makes me answer emails at night. No one texts me to ask me why emails aren’t answered. I don’t have these expectations of the managers that work for me, and if they were to do this to their Engineers, I would rectify that myself, immediately.

Notice that he doesn’t address whether he actually works weekends and nights.  Maybe he’s just a happy Amabot.  🙂

My final thought it that even if Amazon were as the NYTimes article described, it would be a legit approach to business:

“Amazon is O.K. with moving through a lot of people to identify and retain superstars,” said Vijay Ravindran, who worked at the retailer for seven years, the last two as the manager overseeing the checkout technology. “They keep the stars by offering a combination of incredible opportunities and incredible compensation. It’s like panning for gold.”

For more perspective, read the comments (on LinkedIn) on Nick’s rebuttal, or the NYTimes Article comments.

Posted in Uncategorized | Leave a comment

First 24 hours with the Apple Watch

It’s a pain in the ass to pull a phone out of your pocket when you’re sitting down -especially in jeans.

I pull my phone out of my pocket 30 times/day just to interact with it for 5 seconds: when I get into my car and the kids want to listen to the Disney Pandora station; when I get a phone call to see who it’s from; when I need to see where my next meeting is; when I need to perform two-factor authentication to login; etc.

This is the first world problem that I was hoping the Apple Watch would solve.  My Apple Watch arrived last night and I’ve now had it for 24 hrs, and so far I’m happy.


  • IMG_5558The Modular watch face comes configured to show the current or next item from your calendar.  It displays the meeting title, time and location.  My work week is 80% scheduled these days – so I’m frequently trying to figure out where I should be going next.  Having this available as a flick of the wrist is super handy.
  • Two factor auth works!  Duo Mobile works flawlessly.  I can login to my work VPN by providing my password and asking it to push the request to my watch.  The authentication notification comes to my watch and I can just press approve.  I don’t have to take my hands away from the keyboard.  For services that don’t support push – like IMG_5561GMail – the Duo Mobile watch app can generate passcodes with a few presses (open app, select the account).  This takes away some of the friction from two-factor auth.
  • Starting up a Pandora radio station works.  After buckling up, while my phone (in my pocket) is establishing the bluetooth connection to the car radio, I can open the Pandora app and click the “Do You Want to Build a Snowman” station, so my daughters and I can play name-that-tune and sing along on the ride to school.


  • There’s a whole bunch of apps installed on the watch that I’ll never use and I cannot delete – e.g. stocks, weather.  They’re just taking up space and making it harder to find the few apps I want to use.
  • By default the Activity app is everywhere: in the glances, sending you updates every couple of hours, sending reminders to stand up, etc.  I had to go into the settings and turn off 6 different notifications to get it to shut up.  And I still can’t remove the app from my watch app screen.
  • By default all app notifications start out enabled on the Apple Watch.  And to make it even worse, audible notification is turned on.  So there I am in my first meeting of the day and Ping Ping goes my watch.  I suppose that if they defaulted these to off few people would enable them.  So instead this forces everyone who gets an Apple Watch to go through the full list of apps on their phone and disable notification mirroring on most of them.
  • I can’t help but wonder if this will open up a whole new channel for distracted driving.  Incoming texts, Tweets, Facebook notifications – all distractingly in your field of vision.  I wonder if they could add a driving mode that suppresses notifications while in-motion?

I bought the lower-priced Apple Watch Sport, which – at $400 – still makes it by far the most expensive watch I’ve ever purchased (also: the 3rd watch I’ve ever purchased).  Fortunately I can afford a $400 experiment with new technology.  For many this is still an unaffordable luxury.

What will be extremely interesting to see is what the replacement cycle looks like.  People hold onto their luxury watches for many years.  Will the Apple Watch be like an iPhone (replaced every year or two) or more like the iPad (replaced every 4 or 5 years)?

Only time will tell.

Posted in Uncategorized | Leave a comment