Why CEAi?

A few reasons! For context, I recently started helping out over at CEAi. After several years of running my own companies, I decided to join forces with Bradford Cross, because I have wanted a new way to launch startups, find product-market fit, and scale companies, at scale. How do you build a better meta-startup platform? And where do you start, what do you do first? Lots of fun questions, but these things below were my starter hypothesis:

Artificial Intelligence

AI will eat the world.

I’ve been a Lisper for a long time, I’ve enjoyed all the AI books from back in the day, and often wondered when the “AI Winter” would end.

It certainly ended!

With more and more powerful (and cheaper) computing power, newer algorithms are becoming practical, both from a speed and cost perspective. Software was going to eat the world, now AI will eat the software that isn’t using AI techniques.

Cutting Edge Problems

The type of stuff that we’re working on at CEAi is pretty awesome – starting with Merlon Intelligence: an AI driven platform to manage end-to-end financial crimes and compliance (FCC) for banks, insurance, fintech, cryptos etc., to real-estate investment platform that uses data and AI to price homes (B&B), to cyber insurance (TowerStreet), to managing clinical trials using digital mobile end-points (HealthMode), and a new automated trading platform for multiple digital assets (Q).

And many others coming up over the next 2-3 years. Exciting stuff!

Abstractions

Further, I believe in the power of abstraction. At CEAi, a venture studio, we’re refactoring everything that goes into building the companies themselves.

Shared services across business functions such as recruiting/HR, sales development, marketing and growth hacking, etc – these are all often much more powerful and impactful to a startup than just pure software.

And so we’re building these abstractions upon which to instantiate new startups.

Startups!

I’m a huge startup fan-boi. Creating something from nothing, this is what innovation is all about, what the hustle is all about. Sure, not everything succeeds, but that is ok!

Venture Capital, as an asset class, returns pretty poor results – about 7.5%. For all the grand talk that VCs output, this is a pretty shitty showing 🙂

This is all because of the fact that pretty much only 1 in 20 startups really do anything for the IRR. The goal at CEAi is to create a better platform to launch new startups off of, and use all the organizational shared services and learning, to improve these rates. If we’re able to make 1 in 2 startups fail (or succeed!) then we’ve just improved the numbers by 10X. Heck, we’re shooting for a 4X improvement.

Global

CEAi is truly global – we are 2 years old, but thanks to an explicit design decision to be truly distributed, we have 7 offices (and counting!). These include SF and NYC in the US, Prague, Bratislava, Brno, and Kosice in Central EU, and Bangalore in India. Next – probably Budapest and Vienna, along with Tokyo and Beijing/Shanghai.

We go where there’s business and talent!

What’s not to like? 😉

So that is it – doing fun stuff, building amazing things from scratch, the hustle, the game, it’s all here! And that’s why CEAi.

Algorithms will save the day

As we continue our journey to transform the online business at Staples, one thing we’re using to guide our product and technology roadmap is automation. We need to optimize on several axes – speed of operations, (and actual throughput), efficiency, correctness, and cost.

Given the size of the business at Staples (the various online pieces combined are several billion dollars a year), we’re moving as much heuristics as possible into automated decision making systems. This will allow us to improve end-to-end throughput, while optimizing revenue and profit, and reducing cost. Similarly, all incidents will be tagged and tracked, so we can do root cause analysis, eliminate potential sources of defects, and even stop the line if needed.

Take, for example, our new expanded catalog. For a long time (over 25 years), we sold less than 30,000 SKUs, all related to office supplies. In the past year or so, we’ve rapidly expanded our assortment. We’re adding whole slews of products, one vertical at a time. For instance, we recently added hospitality, and retail. If you’re a business in those industries, you can now not only buy your office supplies from us, but anything else you need to run your business. You run a restaurant? Buy your cleaning supplies, cutlery, glassware, etc. from us as well.

We recently crossed 500,000 SKUs on offer, and are on track to cross 2 million soon, and over 5 million within a couple of years. The question, of course, is how to market these new products and to whom. Manually devising strategies to market to the right target audiences has its place, of course. At the Innovation Lab, we set our data scientists to work on this problem. By analyzing all available data on the millions of customers we already have, we’re able to figure out what industries a large number of them belong to. We can then automatically show them relevant new products when they log on, or when we send out promotional emails.

Even where we don’t have comprehensive information about our customers, we can computationally determine several things about them. For instance, can you guess the industry someone within an email address of janet@peninsuladental.com belongs to?

Another example is shipment delivery estimates. We already have a world class logistics platform, having been in the business of receiving orders, fulfilling them, and getting them out to our customers within one business day. As we expand our SKUs though, a larger and larger number of our products will be dropshipped by our vendor partners. The variability on these items is much higher, and the shipments tend to be slightly slower as well. By using historical data around inventory levels, handling times, and shipping carriers’ actual delivery tracking data, we’re able to predict when an item is going to reach a shopper with a very high degree of precision. By communicating this to our customers up front, we’re able to provide a much better experience online.

These are just examples of the several projects we have in the works here at the San Mateo based Staples Innovation Lab. Others include things like real-time selling price optimization, smarter personalized email content targeting, dynamic and personalized product bundles, hyper-personalized product recommendations, a new e-commerce search engine, and several others, for this year alone.

The path forward is clear – automation is the key, and algorithms will save the day 🙂

P. S. – Watch for these project as they go live on Staples.com. And if you’re a technologist, interested in joining the journey we’re on, email me at amit@stapleslabs.com, or check out www.staplesinnovationlab.com

Make something people want

Cross-posted from Zolo Labs.

I’ve been reading Paul Graham’s essays for a long time: since 2001, when an old friend introduced them to me. I was excited by the way he writes about startups and what startups can accomplish. In my head, startups are like the Rebel Alliance, with the odds heavily stacked against them, and they battle the various Death Star corporations for a slice of the business, to institute a smarter way of doing things.

I was also heavily influenced by his articles on Lisp, particularly this one. It’s why I started playing with various Lisps, and why I was so excited by Clojure, and why I wholeheartedly embraced it.

But this post isn’t about technology. It’s about the Rebel Alliance. It’s about two guys in a makeshift office, in the proverbial garage somewhere. Startup statistics can be quite depressing, with 19 of every 20 startups doomed to failure. With such a low rate of success, how do the successful ones do it?

I remember reading this article by Paul Graham, and thinking it makes sense. I remember it making sense in a very superficial, non-committal sort of way. The core of the statement: “Make something people want” seemed perfectly obvious to me. How could you succeed if you didn’t make something people wanted? Duh. Right?

I’ve been spending a lot of time thinking about Zolodeck, the depth of this idea is actually hitting me quite hard. There are two parts of any tech startup: the product side, and the distribution side. The product side is about finding the product/market fit, about making sure the experience is right, and that what you charge for the product is more than what it costs to make. The distribution side is about customer acquisition. Obviously, there’s interplay between the two sides.

“Make something people want” is a simple recipe for success. It seems to distill everything the Lean movement talks about into a single sentence: is your startup making something people want? Everything else is details (of course, the devil is in the details, and you need the details to succeed). In the end, you have to collect and collate the metrics that will point you to what it is that people want, and that will tell you how and what your startup should be doing. But the overarching guiding principle is very sound: make something people want.

And yet, a lot of startups fail because ultimately they don’t end up building something that enough people find value in. Or perhaps at a cost that was lesser than what they could charge for it.  Making something people want doesn’t mean that if you build something incredibly powerful and useful, but at a gargantuan price, you’ll succeed. The something you build for people needs to solve an equation that involves cost, price, scale, and utility.

So back to the two guys in their garage. If you’re a tiny startup (in reality or in spirit), you can greatly increase your chances of success by using this mantra as a guiding light: make something people want. And make use of Lean metrics to see if you’re trending towards a success or failure. I really do believe that if done right (pick the right metrics, and make adjustments based on what they say), a startup can succeed. And given the stats on startups, this is a bold claim.

I plan to share our Lean metrics dashboard and overall progress as we continue to work on Zolodeck. I think of it like a public experiment. Hopefully, we’ll discover something of value, and others can benefit too! Go Rebel Alliance!

Facebook and the MMVP

Cross-posted to Zolo Labs.

I didn’t realize just how true my previous post about the minimum MVP might end up being. When we first conceived of Zolodeck, we figured we’d build it the Lean Way. In that process, we came up with an MVP – and this included support for LinkedIn, Twitter, email inboxes (GMail, etc), and possibly, Facebook.

Now, however, given our time constraints, it looks like our first (pre) alpha (is that even a real term?) users are going to start with Facebook only! Every time we started planning our initial alpha public release, our burn-down projection would show something horrendously far into the future. So we kept cutting back, and we think we have something now. Something that we’d want to use ourselves.
 
I’d have never believed myself if I’d told me I’d launch with just Facebook. But in some ways, this narrowed scope is actually better (apart from being doable in a reasonable amount of time). It will give us a slice of functionality to test, all the way through one end to the other. Our other sources of data (email, LinkedIn, Twitter, etc) are extremely valuable, but they can easily be added later. Just having Facebook means that we can focus on the value-add of our app, rather than just having data from all over.
 
In any case, we’ll see what our users will say 🙂  

Love and the minimum MVP

Cross-posted to Zolo Labs.

The start of a new project is always exciting… there’s the anticipation of awesomeness that can make one giddy 🙂 It’s the potential of the idea, the opportunity of the clean slate, the possibility of applying all learnings to date, and the hope of doing things right

Of course, a business is more than just the product. Somewhere, there’s got to be money involved. And for that, there have to be people who get enough value that they actually pay you. And that you can take in more than you spend to provide the service… 

Here’s the thing, though: if your product is in a “new” space (hasn’t everything that could be invented, already been invented?), then how do you know if you’re building something anyone cares about? This is where the minimum viable product (the much talked about MVP) comes in: the idea is that you build just enough for your early users to try out the product and give you critical feedback that would help you understand the market and its needs. Obviously, these early adopters are not the majority, so the data gathered needs to be adjusted accordingly.

So far, so good – the MVP approach looks really good for new products. For Zolodeck, for instance, we came up with what we thought was a fairly thinly sliced product. What we didn’t count on was that since Zolodeck is still a nights and weekends project (a labor of love, if you will), we don’t quite have enough time to build the MVP of our dreams. So we’re now building a minimum MVP. We’re calling it, wait for it… an MMVP. 

Given that we’re so resource constrained right now, Lean ideas really help. And the MMVP takes this to an extreme – we have to choose just those 1-2 things (maybe just 1 thing) that are the most important to test right now. We really need to think through prioritization of our feature road-map, and decide what to build next. The prioritization needs to take into account everything we can think of – product/market fit, business and technical risks, and so on.

We’ll post updates here as we make progress. For now, we’re hoping to get something into the hands of our first dozen users in the next couple of weeks. Stay tuned!

Designer-driven vs. metrics-driven product design

Cross-posted to Zolo Labs.

An interesting question cropped up over dinner the other night – does metrics-driven design have any place in the world of designer-driven product design? For instance, Apple is famous for not using focus groups and so on, and instead relies on their own processes and practices to develop their amazing products.

I’m a huge believer in Lean methods for developing products and building a business (I’ve written about this before, and spoken about it as well). I’m also a huge Apple fan-boy (yes, I wept when Jobs passed). And obviously, Apple does a lot of things right when it comes to developing products.

So how do these two ways of driving product design mesh with each other?

My point of view is that they’re not mutually exclusive. While there’s no substitute for vision (and thereby designer-driven product creation), metrics can serve as an excellent sanity check. They’re really guard-rails, guide-posts, safety-net, compass, or whatever analogy you want to use. They can be especially useful when the product is in a “new category” and where there may not be established usage patterns or user behaviors to draw from.

If you buy into the “iterations are awesome, fail-fast, learn-improve-repeat” process, then you really can’t do it without metrics. And, of course, you need the right metrics, but that can be a post for another day.

Metrics Driven Product Design

Cross-posted to Zolo Labs.

I’ve had some downtime from work recently, and have been working on a side project with a friend. (Isn’t that what vacations are for?) We’re calling it Zolodeck. One of the first things we did is decide that we want this to be driven completely by future users. So this is an experiment in user-driven product design, you might say.

Technically, we’re tracking everything that a user can do. This data gets fed into our data-digester. Yes, that’s the technical term. And out comes Insight. The idea is to use these insights to decide how to evolve the project.

We’re looking at several ways in which we can get the infrastructure to support all this, including building out our own. I know it will be a complete distraction from the goal of the project, so I’m certain we won’t go down that route. We’re still evaluating what we’ll end up with, so stay tuned on that. We do want to document our experiment here, so this notion of “metrics driven product design” should be a recurrent theme on this blog.

BTW, we’ll also add convenient text-boxes that users can use to drop us notes (mostly appreciative suggestions, but also hate-mail if they choose 🙂 ).