Mitch's Blog

I want to tell you about my new project, Bit Lasso Reveal.

For years, I’ve worked on slide decks. Hundreds and hundreds of slide decks–sales decks, strategy decks, roadmap decks, investor decks. I did a few presentations before founding Pancetera, but my real introduction to PowerPoint was building the pitch deck for that company. Building a presentation that would raise millions of dollars took an entire summer of monkeying with PowerPoint, and after a few weeks, I remember telling my cofounders I suddenly understood how to make decent decks. I didn’t, really, but I had gotten a lot better at it.

I ended up with over 100 versions of that original pitch deck on my laptop. What is it about slides that causes so much version sprawl? Every time we present, we make changes–the audience was confused by a picture, something felt out of order, a key element was missing. But we never know for sure: did we make the deck better, or worse? Let me throw some of these slides in the back.

Collaborating also leads to sprawl, with copies of decks floating in email, cloud drives, attached to tickets or Wikis, posted in Slack–it’s a huge mess.

So switch to Office 365 or Google Slides and be done, right?

Well, not really–these just move the problem around, but they don’t change how we work with slides.

In fact, slide search is a recall problem. “I know I made a green competition slide last fall.” How do you search for that in Spotlight or Windows search? Well, you could type in a few key words, but everyone who has done this knows what you get:

A bunch of slide covers. You can see in the screenshot I have lots of versions of a deck I was working on a few years ago. How can I quickly find the specific slide I want? I can’t! I have to open the decks up and look through them manually.

This is madness!

But with Bit Lasso Reveal, I can immediately see all the “How It Works” slides I have for these decks. I don’t have to open the decks up, and the slides are automatically stacked into similar piles. You can see I have a number of variations of these slides, as I evolved the concept over months of thinking about it, and now I can see a complete history of those thoughts–perhaps at some point in the past, a concept was removed from a slide and I’d like to get it back–with Reveal, I can identify those changes over time.

The best part: Reveal doesn’t require any changes to how you work. You can carry on in as tidy or as messy of a fashion as you’d like. Go ahead and put slides in email, on your desktop, in Dropbox, or OneDrive, or all of them–Reveal doesn’t care. Reveal automatically finds your slides and organizes them in its own database without altering your content. Reveal can even associate slides that you have in both Keynote and PowerPoint versions!

Reveal is available now on Mac, and I know a lot of PowerPoint activity happens on Windows, so you could imagine I’m working on that. Comments? Feedback? Suggestions? I’d love to hear from you. Write to mitch@bitlasso.com or tweet at @bitlasso

P.S.: As a bonus, here’s a picture of the slide comparison:

In 1968, Dr. Melvin E. Conway published an article called, “How Do Committees Invent?”

In this paper, buried towards the end, is the following insight:

organizations which design systems […] are constrained to produce designs which are copies of the communication structures of these organizations.

Thinking back on my product experiences, this has been the case every time. The cracks in products show up where teams didn’t talk to each other, where two people didn’t get along, or where someone wasn’t willing to pick up the phone and call someone else. Features or modules that integrated well and worked smoothly reflect where two or more people worked well together. In cases where one person went off by himself and re-invented the wheel, sometimes even large core parts of a product, led to internal difficulties and those internal difficulties turned into product difficulties when the product shipped.

As an engineer, every time you don’t pick up the phone to call a colleague about an integration point, you’re making life harder on your customer. As a manager, every time you don’t deal with someone not communicating, you’re making life harder on your customer. Meanwhile your competition who play well together are building beautiful products that flow.

The communication successes and failures of an organization are independent of the organization size. It’s fashionable to say that small teams work better than large organizations (37signals vs Microsoft), but in fact, a small team can be incredibly dysfunctional, just as a large organization can work well (many start-ups vs Apple).

Of course, the scope of “systems” goes beyond products. IT deployments–if your VPN guy and your Exchange guy don’t like each other, how many times do you have to login to different computers? Marketing strategies–700 folks clicked on an emailed link, but did those people have a good experience on the landing page? Sales operations–much time was invested in segmenting and building custom collateral but were those materials used or ad hoc assembled in the field? Manufacturing–sure, everyone signed off on the Micron chips, but “someone” decided to build half the boards with Hynix and didn’t tell anyone? Support–Is your support experience congruent with the product, or is it outsourced with its own login, and the support folks have their own culture?

A team that doesn’t communicate openly, frequently, and freely is expensive to operate and builds lower quality products, end-to-end.

Recently I received a query via email that I thought would make a good blog post:

How do you conceptualize what software would be useful to an industry? More specifically, how did you determine that VMware storage automation applications would be useful in a large context to industry, and how did you design your method of accomplishing this task to be more efficient and desirable than the internal to VMware and your competitors?

You don’t have to answer in specifics of course, but I’m suffering from a classic “coders block” on applications that might be useful to a broad context and wondered if you had any advice on that topic.

I have brought seven products that I either invented or co-invented to market, and worked on about six other products in a major way.

The products that were successful came out of the following criteria:

1. What am I uniquely able to bring to market? I.e., what are the capabilities of my own technical skills, knowledge, and other people that I know who I could convince to work for me? What scope of products can we create? What ideas, out of that entire range of possibilities, are unique and are based on insights or experiences that few others have?
2. What’s missing from the market place? Of the things that I can uniquely do, what of those can be applied to things missing in the market?

Any market worth being in is busy. If no one is there trying to make money to solve the problem you’re solving, with some type of offering, it’s not worth being in that market. Some of the market scoping you can decide–and how you decide this will drive how you talk about your offering. If you scope too narrowly, no one will fit your target audience. Scope too broadly and no one will be able to find you. Sometimes it is tricky to know what market you’re in; you might think you’re selling software, but your customers buy your product as insurance. Or maybe you think you’re selling shirts but you’re actually selling a lifestyle.

My first serious business was a Mac software business, selling casual games that were targeted to smart women in their 40s who wanted a tough mental challenge. This was an underserved market at the time–few casual games existed beyond Tetris and few were sold with a concept of being “difficult”. Anyone can “match three” like Bejeweled, and lots of people like doing it, but can you solve this puzzle? With my first product for that business, I hadn’t quite identified what the target was–in fact, the first game was more of a concept test–could I finish a product, release it, get people to my web site, get them to give me their money, send them a license key, support the software, and so on? As it turned out the answer was yes. The second game I did was much more targeted to my audience defined above–and sold 100x more copies. While there was nothing specific in the game tailored to women, and I certainly had plenty of male customers too, I wrote advertising messages and picked placements that were targeted to women because I felt that my message was unique and unexpected vs other ads women might expect to see in those places.

The word “innovation” has gotten a lot of attention these days. I took a class at MIT’s Executive training program last year on managing innovation in large organizations. One of the key things one of the professors pointed out in the class was that innovation without solving a customer need is completely useless. This should be fairly obvious, but I’ve seen plenty of people lose sight of this fact.

So when you’re building a new product, you need to be solving a real customer need. That brings us back to the original question: What process enables you to figure out what would be useful?

At my last company, my partner and I spent hours just chatting about ideas–I would estimate over the course of four years, we spent over 800 hours brainstorming. What if there was a way to do X? What about Y? What if you did Y but with a hint of X? Would anyone care? We were developing products in an industry that we knew well–I had about 4 yrs of experience in that market and he had about 15. So we knew a lot of the attitudes of our customers, a lot of the concerns, some of the common problems that those customers face day in and day out. We were bringing our understanding of that market to a semi-new but semi-related space. We kept the brainstorming going from the very beginning when we first had the idea all the way through until when I left the company after we were acquired. We came up with several ideas for things we never shipped and a few key ideas that we did ship and did well.

Tied into our brainstorming, we did a lot of market research. Long before we had employees or venture capital, I was pounding the pavement, visiting customers, calling customers, searching Google for people posting in forums about the problems we wanted to solve, and posting on Twitter inviting people working with certain tools in Boston or San Francisco out for having a beer with me. We also did surveys with Constant Contact to help quantify what we were finding organically with people we could manually reach. The organic side helps find stories, and structured surveys with the right audience can help define priorities or narrow a focus once you’re able to describe better what you think is important.

If you want to build something big, you need to attach to a market trend that is real. Lots of people understand this, which is why you see so much “Mobile is the next big thing”, “Cloud is the next big thing”, and so on. But you still have to solve a real problem–in a market trend that is real–and not get creamed by the big players in that space. We felt the virtualization trend was real, so were comfortable attaching to that. Lots of companies saw this as well and tried building small, simple products, such as performance monitoring tools for VMware–but VMware is good at adding those features pioneered by third parties to their own management applications. At the end of the data, these companies were just publishing numbers exposed by VMware APIs into a UI or reporting system. The bar to duplicate that was very low. So you have to focus on problems that are hard to duplicate or spaces that are related but not in the big vendor’s core competencies.

There’s lots to be said about the process of inventing new products. Many people talk about Clayton Christensen’s book The Innovator’s Dilemma, but from a process perspective, some of the activities discussed in one of his other books, The Innovator’s DNA, is worth reading to see how folks approach solving these problems. I have had a copy of The Product Manager’s Desk Reference by Steven Haines in my bookcase for a while now, and while I haven’t read it cover-to-cover, it does cover a number of the research activities required to build a new product all the way through launch. And of course, there is the classic book Winning at New Products by Robert Cooper.

Elsewhere on this blog, I have previously written about some related issues with starting a new company. If you are starting a new company, be sure to check it out!