Monday, August 20, 2012

How to Start a Business in a Competitive Market

Editor’s note: This guest post was written by Jonathan George, founder and former CEO of Boxcar.io — the first push-notifications-as-a-service platform for iOS - which he recently sold to Kwaga

You're starting late.

A few years too late or maybe just a few months. Either way, you're already running behind someone else. They've learned a few things that work and some things that don't.

Your natural reaction is to look at what they've built and start to build it yourself, too. All of it. Every little feature, you think you need to match.

You don't.

Stop worrying about playing catch-up with the other people in your market. Forget all of the extra bells and whistles that they each have. You have limited resources and you'll just spend forever chasing instead of pushing the entire market forward.

Focus on the core problem, release and expand outward from there. The rest of the functionality will define itself as you become more intimately familiar with the problem domain you're working in.


When he's not peppering fellow startup founders with inspiring sentiments, Jonathan is mentoring startups and building great teams to fearlessly attack big ideas. He blogs at jdg.net



Friday, August 17, 2012

RFID vs. Barcode: Why Inventory Processes are Seeing Red

At a company I previously worked for, we implemented solutions for tracking inventory. We were using a 3rd-party-supplied mobile platform to track inventory and push all the data into a big, expensive, well-known asset and business process management suite. The companies involved were all Gartner magic-quadrant vendors, but the reality was that the solution still generally sucked, as most all such software applications do. Don't get me wrong, these companies are pushing hard, but they're still light-years behind where they could be.

It turns out that inventory management is hard to improve upon without taking on a big, risky investment. Thus, in most companies, cycle-counting is still a drudgery and though mobile apps have improved this a bit, its still a big tedious effort. And yearly inventory audits are generally still nightmarish. You would think that there's enough money tied up in these processes that someone would have solved it by now.

They tried to solve it with RFID. That was the darling concept of the mid-to-late nineties. Companies fell over themselves trying to find out the merits of this ground-breaking idea. Some, such as America's largest retailer, even made bad PR mistakes by touting their forward-thinking inventory requirements which all hung on implementing RFID. Turns out, most business analysts couldn't get past the one sticking point with using RFID for inventory:

  • It doesn't really solve any inventory problems.

The core of inventory management is knowing what you have in stock, not just guessing. Waving an RFID wand at a box or a shelf or walking a box of parts through an RFID gateway may give you a warm fuzzy feeling, but what it doesn't guarantee is an accurate count. It provides a guess. And by that I mean, unless you open the box or climb up on the shelf, you can't really tell if the inventory count is correct, or if some sneaky person just left the RFID tags and took the item or if there is a piece of lead sitting on top of your item.

RFID is generally an expensive way of giving you a guess as to whether there is really inventory that you expect to be there, and that really is the best case. Its expensive because the good tags aren't cheap and the inexpensive ones aren't detectable from a distance. If you have a warehouse of any size, rolling out an RFID implementation can run in the 6-digits from the expense of the tags themselves to the labor cost of training of workers and the actual installation of the tags. And when its all said and done, you have software and hardware that lets you guesstimate the inventory count. Nice.

Where RFID shines is in larger assets where you only want a sanity check. For everything else, its line-of-sight plus paper or good old red-laser barcoding.

Tuesday, August 14, 2012

Broad vs Narrow Marketing: Observed Outcomes

I am in the lucky position of being friends and business partners with a very sharp, very forward-thinking researcher and marketer by the name of Matt Tharp. Matt is currently focused on his new blog BreedLikeHabits, where he will be focused on writing about behavioral analysis with respect to its applications in internet marketing. In a recent conversation, he imparted some anecdotal wisdom to me concerning his experience with broad versus narrow marketing, in which he said:

"Marketing is easier to ramp up when you know exactly who/what you're targeting. For a long time, web companies in the post-bubble era have been marketing to "people looking for product x", which has worked OK for a lot of those businesses, but it has rarely allowed them to create a more proactive marketing approach until they started focusing on one (profitable) target audience. At that point, they are finally able to begin marketing to decision-makers and are able to grow faster.

I've worked at two companies that have tried the broad and the narrow audience approach. One has always effectively done vertical segment and persona marketing, which allowed them to focus the message and content. The company that focused on the narrow audience approach started the same year as the company that followed the large-audience approach and grew to essentially 30x the size in the same period."

Its an interesting and telling anecdote if two companies, presumably with similar market sizes, would have so much different outcomes by using two predominantly different marketing approaches. Certainly there could be other factors, but Matt's anecdote lines up with what a lot of other folks have been pointing out: if you want to be successful in growing your business you first have to know who your audience really is.

If you're not following Matt, you should. He has a lot of things going on under the hood at BreedLikeHabits that will be surfacing soon.

Saturday, August 11, 2012

Apps for the Enterprise: Upcoming Topics

In the coming weeks, as I'm wrapping up my first Startup Blog Topics series, I'm going to shift gears and start talking a bit more about the implications of building apps for the enterprise. If you're building software for enterprise clients, or are looking for software solutions to meet your enterprise needs, we'll be touching on topics related to that. Upcoming (varied) topics include:

  • RFID vs. Barcode: Why Inventory Processes are Seeing Red

    RFID solutions are relatively simple and cheap to implement, so what is preventing companies from adopting RFID in a meaningful way? Why is barcode asset tracking still the inventory method of choice for many applications?

  • Features that Sell Enterprise Products

    A brief look at a few features that your product is going to need if you expect to sell in the enterprise market.

  • How to Price Products for An Enterprise Market

    When it comes to pricing, the enterprise is more practical than you think. In this post, we'll go into a few ways that you can create a justifiable price-tag for your products.

  • The Mobile Platform Paradox

    Large companies are so used to using 3-5 year-old technology, but the mobile space has so far surpassed what the enterprise is doing that they can't keep up with the shift, and its creating pressure to continually reconsider their platform of choice.

  • Employee On-boarding Done Right

    Some companies' employee on-boarding process is straight out of a Dilbert comic. No guidance for day-one, no training, no meeting with upper management, no meeting on expectations, no on-boarding followup. This stuff shouldn't be this hard. We'll look at ways to do employee on-boarding right.

I'm jazzed to write about a few of these topics, and I'll link the title of each to the actual post once it's complete.

Monday, August 6, 2012

Building Products for the Enterprise Market

"Large companies are quite price-sensitive... Corporations will always base their purchase decisions against their internal cost of building the same products... You're out of the running if you use the wrong technology."

A week ago, I listed a set of topics that I would write about soon. I'm excited that I'm already getting to this particular topic, but I also feel bad because my startups need TLC and I'm procrastinating. So it goes.

Note: This post is based on anecdote and my experience inside several medium and extremely large companies. If you have your grain of salt ready, then lets get started!

1) Believe it or not, large companies really are price-sensitive when it comes to buying products

I know that nobody in software likes to say this, but its true. After all, companies are staffed by individuals who bring their own biases when researching software solutions. Often, large companies are price-sensitive enough that in the world of B2B and B2C marketing, they like to lump these folks in with the B2C market so that it doesn't destroy their marketing paradigms. But, it really is surprising, having worked inside large companies, how very price sensitive they are.

Now, a large company isn't going to balk at a one-time purchase that varies $20 to $50 from the low-end solution, but they do get consternated about cost differences when it scales. So whereas in pricing your product you may think in terms like "I can sell this company a 10-seat license. At $50 per-seat license, their costs will fall in the comfortable range of $500/year", they're thinking "Well, geez, what if we expand and roll this out to 10,000 users, those $50 per seat fees are going to eat us alive!" Businesses in growth industries tend to translate those prices into a much larger multiplying factor than what you may be targeting, even if their current expected number of seats makes your software interesting at first. So if you're selling per-seat licensing, at the very least you may want to include price-breaks at certain levels to bring that price down into tolerance, because corporations will make somewhat ridiculous calculations based purely on a potential for expansion.

I worked for a software product company once where we brought in a reporting-solution vendor that we were considering for integration into our $30,000 application. Understanding our price points, they wanted somewhere in the neighborhood of $100 per installation. I had done the evaluation and the company demonstrated every kind of integration we wanted and it played very nicely with our software. I was surprised when the vendor came huffing out of a close-door meeting along with his regional sales manager and our marketing team. They seemed quite put-out. We wanted a price in the range of $30 per installation, 0.1% of our install price.

2) Corporations with IT shops will always perform a buy versus build analysis

Oftentimes, it isn't even important that they can get the software 3 months sooner by buying it from you. Some companies certainly may have what they call a time-preference, and it matters a lot to them to get things faster. But companies are so used to buying software that takes months to integrate, and are so used to planning months in advance for things, that unless it solves a real pain point right now, a time preference just doesn't factor in as an advantage for you. But, where you can almost always compete is on a price basis that is relative to their internal costs.

Where I worked before, they had internal per-hour costs of between $75 and $100/hr. So whenever they would estimate something, they multiplied the projected number of hours to complete by those per-hour values to arrive at the estimate. That will be the basis of comparison. If the cost is less or it's about the same as buying it off the shelf, and it creates a new internal capability for them, then they'll choose to build instead of buy. If the cost to build it internally, after factoring licensing and consulting support costs, if it costs less, they will build it themselves. So, there is a limit to what companies will pay. It's not as subjective as you think.

Another caveat: If you are selling a completed large software package to a business with an IT shop, then there is one extra benefit where you can capture enormous value that throws out the whole "What would it cost if we built it?" calculation. That benefit is that the product is complete. And by that I mean you successfully built it. This is a benefit because corporate IT has a long history of failed software projects, and they tend to have doubts about their ability to build fairly complicated software internally. This is probably where the most blue-sky is sold in software. If that isn't the primary driver for IBM's and Oracle's success (its probably brand at this point) then its a secondary reason.

So it may seem arbitrary from your perspective, and you think "Geez, companies really pay a lot for software", its really not arbitrary at all. Its just that their tolerance for paying is based on their internal costs. Its not really a value perception, its whether they can build it or not or whether they will get any other benefit from building it themselves (such as training the new guy to develop apps).

At one very, very large firm, I was tasked with evaluating mobile asset tracking software. The vendors were very astute. They were charging very close to what it would cost us to build the same solution, so to us the pricing was very reasonable, and it had the added benefit of ongoing support and limited upgrades. However, they lost the bid simply because we felt like we wanted to develop the mobile development capability within our staff.

3) You're out of the running if you use the wrong technology

The #1 requirement you're going to run into all the time is that companies want to self-host their solutions, and if they want to self-host, they'll probably only tolerate 3-4 technologies. Generally those technologies are:

  • .Net
  • Java
  • +1-2 random scripting languages (Perl, Ruby, Python, etc). Typically, these are only used for batch scripting, so don't get your hopes up.
If you're building a product that allows large companies to self-host, congratulations, you're halfway to an acceptable enterprise app. However, if you wrote the application server in Ruby, you probably won't have much success selling it. This is because companies won't want to have to bring their staff up to speed on Ruby to support it. So if you're going to write self-hosted client-server software for large enterprise, you need to consider building your product in Java or .Net. Also, you better build your software with the idea of integration with their existing systems otherwise, again, you'll be out of the running.

More about architecture considerations in an upcoming post. Also, in an upcoming post, we'll talk about an actual list of ideas for products you could build for this market.

[1] Note: We are really talking about price-sensitivity as it pertains to total-cost-of-ownership. In per-seat or per-installation licenses, they go nuts when the price is $20 more, but 1-time purchases create much less chaffing, even when there is an order of magnitude of price between competitors.

Friday, August 3, 2012

Generating Tons of Value While Lacking Focus

The reason why people want focus is because when they are unfocused, they don't seem to create much value. But, what if you could create as much value when you're completely unfocused? Lets spend a few minutes looking at that.

First off, when I talk about an unfocused individual, I don't mean lazy and tired and lacking motivation, I mean that they have a great amount of energy, but they can't seem to direct it at the right stuff. You're excited, energized, but you don't know how to use that energy. This is a common problem among lots of bright, talented folks.

The Power of Having Focus

We understand that focusing on a single idea to the exclusion of other things, is generally very productive. When you have focus and you're in the zone, focus is a multiplying factor for getting stuff done. Distractions are an inverse multiplier for creating productivity.

That's why, in a workplace setting, some great developers won't even talk to you until they've purged their entire cache of code before stopping to speak with you. At a company I worked for a while back, there was a developer there who would spend 30-90 seconds finishing his thought before we would even turn around and address you. It was awkward for everyone, but that was his way of clearing his cache and making sure he found a good stopping place he could return to at the end of the unwanted interruption.

Mental focus allows us to have a single, unbroken line of connected thought. It allows us to do a deep dive and see the next 10 moves we want to make. It allows us to be come the Bobby Fisher[1] of coding, of accounting, of metalwork, of brand analysis, or of real-estate. Focus allows us to see the big picture end-to-end and have all the context for the problem set in our head. This allows us to make smart decisions about how modifications in one part will have downstream effects elsewhere. Whereas, when you don't have the whole context in your head, the small changes you make aren't well thought-out and can have negative effects.

The Power of Lacking Focus

The cool thing is that focus is not necessarily the mother of creativity. Creativity happens in the world between concentration and random thought. If you concentrate on something too specific, it can destroy creativity. When you're in the weeds and unfocused, its a great time to be creative, to brainstorm.

As a developer, at the end of the night when I go home from my day job and I sit down and begin to think about the problems I can attack, the majority of the problems that I want to attack are way too large to fit into the time I have to write code. So, often the best use of that time, when I don't have enough to get into the zone, would be to brainstorm and come up with creative approaches to things, or come up with new ideas for businesses.

So, the power of being in the weeds and unfocused is that you can allow yourself some completely unhibited brainstorming of the most crazy things, crazy ideas that hopefully solve real problems. That's how you leverage a lack of focus.

The key is in recognizing whether you have time to focus, to get in the zone, or not. For me, its a good rule of thumb to say that if I have 2-3 hours of time to sit down and work uninterrupted, then I can knock out a fairly complex implementation and feel good about the result. However, if its 30 minutes or an hour, then I will default to my old habits of piddling around on HN, Reddit, or CNN. And that's where the problem lies, right? I'm using the lack-of-focus time to goof-off instead of being creative. I have defaulted into being a consumer and not a producer. Use that time to play. If I simply could play around with a new concept, whether it's riffing on a guitar, or coding up an experimental app, then that would be a powerful way to use my unfocused time.

Things to do when you can't focus (software startup edition):

  • Draw mockups for that business idea you have.
  • Setup a blog, write a blog post about your product idea.
  • Get out your banjo, harmonica, or whatever, and write a jingle for your business
  • Experiment on how to calculate LTV or COCA in your app.
  • Think of a product hook, that is, a reason for a journalist to write about you.
  • Research your competitors (be careful, this can be a trap), and come up with one feature that you can do better that they can.

Knowing when you have time to focus and when you should be creative takes discipline, because you'll want to default to your consumer mentality. It takes a certain amount of focus to be able to know when to focus. :). But, if you can convince yourself that unfocused time is creative play time, then you can extract a lot of value from that spare 30 minutes or an hour.

Who knew that lacking focus could be a superpower?

[1] Bobby Fisher was a chess champion who could visualize his next 12 moves on the chess board when playing against opponents.

CLOP

This is genius. A game with seemingly simple mechanics, but nearly impossible to beat. You keep playing because it just seems like it should be so simple, and it "vexes" you that you can't seem to get it right. Its also named in a way that makes it instantly recognizable.

Like QWOP before it, its fun, addicting, and awkward.

Its also great marketing for the follow-on apps in the app store, I'd bet.

Here are some ideas for building apps similar to QWOP/CLOP:

  • MOP - A janitor, mopping the floor while leaning on his mop. Clean the floor, but don't lose your balance, else you start over.
  • POP - Your car is driving down a bumpy road and your soda is sitting on the dash board. Swerve to create angular acceleration that keeps the pop can from spilling.
  • PLOP - You're a waiter holding a platter of drinks. Control your arms to keep the drinks from spilling.

It is likely that these concepts don't have all the elements of an addicting game, but I can't help but feel that they aren't far off. Just some playful, Friday-afternoon ideas.

Wednesday, August 1, 2012

Startup Blog Topics: Upcoming Posts

Here are some topics that I'd love to write about soon, or else invite someone to write about with me. I think that doing a shallow-dive on these topics will create enough value that they are worth pursuing, however anecdotal the experience. I think these will have valid, relatable ideas with lots of useful and interesting content.

I will link the titles to the posts when they are complete.

  • How to Get in the Zone, Or Not

    A look at the value of focus and how to attain it. Also, balancing in-the-zone with in-the-weeds, and deriving incredible value from both. I'd also like to title this post, 'Generating Tons of Value While Lacking Focus'. I'm excited about this one.

  • Building Products for the Enterprise Market

    An early look at building products that target an enterprise audience, based on my experience building and analyzing line-of-business apps for the largest private enterprise in the world. Likely this will be a multi-part post.

  • Connecting with Your Customers at the Right Moment

    A look at the reasons why you should move fast on a hot lead, and some tools to let you do that. Plus, how to get the most value out of lead-generation software. With special guest blogger Matthew Tharp of LogMeIn.

  • How to Start a Business in a Competitive Market

    How to attack a competitive market with pure grit and an IDE. With special guest Jonathan George, former founder of recently-acquired Boxcar, who is working his latest, unnamed startup.

Note to self: Wow, now I've achieved the dopamine I wanted without having to actually write anything useful yet, yay! Writing about topics-I-want-to-write-about is addicting, and it generates a lot of extra work for me. I'll need to limit this kind of thing in the future, but at least I'm writing my goals down, right? Right!