Dan Grigsby

40 Under 40

May 9th, 2008

I’m pleased to share that I’ve been selected as a recipient of the Business Journal’s “40 Under 40″ award.

My heartfelt thanks to all of you who supported my nomination, especially to Lars Leafblad (a ‘07 award recipient himself) for thinking of me in the first place.

I’m honored, and in good company: Jamie Thingelstad’s a winner this year too.

Finally, thanks to Graeme Thickins for the kind quote featured in the article.

Posted in Uncategorized | 6 Comments »

RubyFringe: Us: The Sex Pistols. Them: Kenny G.

February 18th, 2008

I’ll be speaking at RubyFringe in July.

Billed as the “avant-garde conference for developers that are excited about emerging technologies outside of the Ruby on Rails monoculture,” the conference looks superb. Pick an emerging Ruby-based technology and one of its leaders — in many cases, its outright creator — is presenting.

I’m honored to be speaking. I’ve already started preparing, just to make sure I pass the muster.

It’s impossible to predict when one of those sublime moments will occur, when a group of really smart people gather and something unexpected and new develops (e.g., the Cluetrain Manifesto, the Agile Manifesto), but RubyFringe has the odds on its side.

RubyForge is being put on by Unspace, the people behind HAML and make_resourceful.

Details: July 18-20. Toronto, ON. Registration opened today. Attendance is capped at 150. The price is a reasonable C$650 for the first 75 people, a still-reasonable C$700 thereafter.

Posted in Uncategorized | 2 Comments »

The Tyranny of CSS And Ajax, A Timex Watch And A Barrel Full of Rocks

January 24th, 2008

A beep; a pause. Another beep; another pause. Third beep; third pause. Eleven beeps in quick succession. Listening to the kid in the row in front of me reset his Timex following our flight one time-zone westward helped me understand why building web apps has been so so little fun recently.

Two buttons provide enough of an input mechanism to set a $10 drug-store watch. Hold down one button, wait for the LCD numerals to start flashing (or, fancy-schmancy, listen for a beep) and plug away at the other button until you’ve cycled forward to the right value. Hold down that first button down if you want a different column of numbers.

By any measure, that’s a crummy UI. Thing is, it’s good enough. It’s good enough for the bottom-of-the-line digital. Moving up-market the UI gets even worse: my REI bought analog watch uses a single rotating stem to set six hands on spread over 4 dials. That’s an arguably worse UI still. But again, it’s good enough.

Sometime in the recent past we traded in “good enough” web UIs for UIs measured against desktop applications. Google is widely credited with ushering in this era. They showed us that it was, indeed, possible to build beautifully interactive web applications using JavaScript to manipulate the DOM. While we were at it, we traded in the limitations of tables and simple HTML for the granularity and rigor of CSS.

Working with CSS and the DOM is aggravating. Plenty of reasons for that [1], most defendable is probably the inconsistencies between browsers. Naturally you can overcome most of these things by exerting effort. That’s effort spent working on something that is, in all likelihood, ancillary to the purpose of your application.

I suggest we take back “good enough” and justify it by applying Barrel of Rocks metaphor of market segmentation.

Sink uses a barrel to represent the total market for installed software. The barrel gets filled with stones whose size represents the size of the market-opportunity. Operating systems and office-applications are boulders; there’s only room for a few of each. Here, a glance, the barrel is full. But, of course, there’s lots of space between the boulders. This space is can be filled with rocks, and the space between rock with pebbles and so on.

With the barrel representing the total market for web applications everything becomes clear: Google, whose applications set the broad market standard for installed-application-like UIs, is a boulder. They want people to switch from installed software to their broad market web applications, so they need these fine interfaces and their market opportunity justifies the time/cost/complexity.

Are you building a boulder, a rock or a pebble? You’re not very likely to be directly competing with Google, nor is your application likely to be a installed-to-online switchover application, so good enough ought to be good enough.

Start simple and carefully add your application-like features later. Focus on features that offer substantive depth (e.g., keyboard shortcuts) over flashy eye-candy to promote power users of your app — see Kathy Sierra’s Engaging Users essay for inspiration.

[1] For a more technical slant on this, you might like Neil Mix’s Beyond Dom article.

Posted in Uncategorized | 2 Comments »

A Plan For Minnesota

January 10th, 2008

Minnesota can attract well-known software/IT companies to establish Minneapolis/St. Paul based “outpost developer offices.”

Repeatable Pattern

I’ve noticed a pattern of well-known software/IT companies locating development offices (as opposed to, say, sales offices) in the Minneapolis/St. Paul metropolitan area.

Adobe is, perhaps, the best known success story: they’ve had a presence in Arden Hills for some time that produces some of their marquee products.

Dow Jones’s Minneapolis office is the home to over 100 developers who’ve built for a large swath of Dow Jones’ online offerings.

As part of my involvement in the local developer and software business communities, I’ve become involved in working with Microsoft to create a product development office here.

Less formal, though no less important, is Sun’s investment in Minnesota: Sun has been quietly hiring some of Minnesota’s best software minds to lead initiatives — some public, others as skunk works — that form the basis for the companies resurgence.

Seagate, Oracle, Veritas and others have engineering offices here too.

Larger Pattern

Though these companies were drawn to Minnesota for a variety of reasons they share a common theme:

Minnesota provides an environment where serious software can be built at a significant discount over coastal alternatives.

Interestingly, the pitch for Minnesota here runs parallel to the value proposition offered by “Indian outsourcing,” though without the negatives.

India Looked Good On Paper

The World Is Flat, Thomas Friedman’s oft cited book, illustrates the pre-conditions that made India appear to be an attractive location for outpost developer offices early this century:

Indian culture/society hold engineers in high regard, and India’s institutions are geared towards producing a renewable supply of well trained, employable, productive engineers. Good engineers paired with what was, effectively, free broad band and lower wages, India held great potential.

To a limited extent, that potential was realized: Large enterprise software development projects — those ERP projects/implementations with armies of undifferentiated developers that consultancies sell to giant multinationals — fit well into this model because the physical distance, the many time-zones that separate the participants, and the language difficulties could be overcome by enormous specifications, volumes of documentation, and Process with a capital-P.

However, companies whose product is software — and this point is critical, i.e., places were software was not a side-effect, were it was not used to support the business, but where bytes were the business (whether installed software or web based) — did not generally succeed in India.

For these folks, all of the front-loaded specification work and the delays in communications that a dozen time-zone bring, cause the process to fall down. You can’t build software this way when software is your product. I won’t attempt to provide a comprehensive explanation of why, deferring instead to 20+ years of research and literature, exemplified by The Mythical Man Month.

Enter Minnesota

We, Minnesotans, have had success building software-as-the-product. It’s illustrated by the examples above and from home-grown success stories like Digital River.

Our culture that values engineers. We have institutions to nurture them. We are a wired state, as evidenced by Popular Science when they recognized the metro area as the Top Tech City.

Developer salaries are at least a third lower in Minnesota than on the coastal tech centers. All in, fully loaded, it costs less than half as much to build software here as on the coasts.

Also, we’re at most two time zones or a few hours flight away. I am, in fact, writing this from an airplane on my way to New York, where I’ll be putting the theme of this essay into practice:

For the last few years, I’ve largely made my living building new software products/services for established coastal companies.
Their examples illustrate the sweet-spot in the market that we should target to draw software companies into Minnesota:

Sweet Suite Spot

My clients are venture backed companies transitioning from “emerging” to “established” status. Their stories follow a similar pattern:

The company is founded/funded to produce a narrowly-targeted piece of software. They succeed, building a “best of breed” application in an emerging space. As the broader market that their product lives in matures, buying-behavior changes: people move from buying best-of-breed applications to buying a suite of applications.

An “historic” example of this is the office-application suites. Recall that the choice used to be “Wordperfect vs. Word,” followed by a later choice of “Lotus 1-2-3 vs. Excel.”

When a company emerge as a market leader, with stand-alone best-of-breed product, only to find the market moving towards buying suites then they very quickly need to flesh out the empty pieces in their roster. They will license other people’s products to fill the gaps where they can and they’ll build the rest.

In the office-suite space we’ll examine the winner: Microsoft bought PowerPoint and developed Excel.

There’s a certain unsubtle difference to building out the suite vs. building a new idea in a virgin space: You’ve got a crib: your competitor has done the work to test out what works in a word processor and what doesn’t, so your job is a bit easier.

But it turns our that building out a suite turns out to be very nearly impossible for companies at this (or any) stage. It took the collective total of their entire engineering team arrive at this point; it’s impossible for them to double down and develop new products with their fully utilized existing team.

At this point, it becomes a balance sheet issue: they need to fill in their suites at minimal cost.

To these folks I say, “Enjoy Minnesota! It’s all here.” We’ve got the talent and we’re affordable.

We can build on our success stories. They won’t come to us, but we can actively recruit these businesses. Identifying them won’t be hard. It’ll take a directed, block-and-tackle sales job pairing the incentives that state’s economic development policy makers can offer with folks like me to literally drive the message home, door-to-door, in Silicon Valley and get these companies here.

Posted in Uncategorized | 9 Comments »

Definition Disconnect / Two Kinds of “Software As A Service”

October 17th, 2007

Most of the time labels and acronyms simplify/clarify conversations. You label something, and maybe shorten it to an acronym, and it acts as a shortcut.

When I talk about “CRUD applications” or “RESTful interfaces” with another developer these terms let us skip ahead and talk about the good bits because we share a common definition.

However, in a conversation with my mom, these same terms obfuscate. Mom hears that I don’t like my work, but I’m trying to relax and maybe take up a hobby.

This disconnect is most damaging when you and the person you’re in conversation with both think you share a common definition when, in fact, you don’t. Let’s call this a “definition disconnect” and press on.

From the management team to the venture capitalists, from the developers to the marketeers, everyone in our industry is wrapped up in a definition disconnect surrounding the term “Software as a Service” that has broad implications for everything from:

(1) how you value your company,

(2) how you build your systems,

(3) how your price your offering,

and

(4) market segmentation.

Keep these 4 criteria handy as you read on.

Software as a Service (”SaaS”) is a term that is inexactly applied to two distinctly different kinds of businesses. Basically anyone whose app hosts its bits in the cloud that would otherwise have been hosted within a businesses’ network gets the SaaS label. This is flawed; here’s why:

Historically, you could split up software products into two buckets:

(1) shrink-wrapped software

and, for lack of a better term,

(2) consult-ware software

Consult-ware might be a contentious term, particularly in an post about shared definitions, but I’m using it as a stand-in for a longer definition about software that comes with consultants who tailor it to match the needs of the company that bought it. “Mass customization software” might be closer, but is hard to say. Heck, it might be enough to say that this is a consultants-vs-packaged software split. Whatever terms you use, read on:

Working backwards through the 4 criteria, consult-ware software:

(4) targeted “up market” customers

because their deep pockets supported a pricing model where

(3) a significant chunk of revenues come from customization/consulting

which requires a

(2) “platform approach” to product building

Conversely, shrink-wrapped software tends to be:

(4) mass-market

with an

(3) easily calculated price structure

that necessitates

(2) a “one-click setup” that minimizes support requests.

I’ve skipped the valuation criteria because covering that would take a bunch of space without significantly enhancing the case that these were two very different kinds of businesses. I think it’s fair to simply say the valuations of Microsoft and SAP should be calculated very differently.

These businesses are worlds apart; this division exists amongst Software as a Service businesses but is largely ignored.

The implications of this are significant, and once again fall along the lines of the 4 criteria defined above. Rather than rehash the same market analysis, which falls along predictable lines, I’ll illustrate this with some observations/pitfalls/considerations:

Many Software as a Service businesses mistakenly place themselves in the consult-ware model. This mistake arises when they embrace broad customization without having a price point (both initial price and maintenance) to support this. This tends to present itself in terms of customizing workflow applications to fit different clients needs.

Smart companies in this situation recognize this and strictly enforce a rule that customization happens at the view-level only. All clients share common models that are populated by customized views. The gotcha here is that your maintenance revenue model needs to support the significant investment keeping this ever growing collection of templates current as you release new features, refactor existing functionality, etc.

Other companies emulate the “one size fits all” shrink-wrapped approach more closely, producing a single version of their software that’s used by all of their clients. Hopefully the app is flexible enough to cover most needs of most people in the market. The common wisdom is that this’ll keep you out of the top end of the market. I’m can’t decide whether I agree with this or not; there are certainly examples of these kind of companies gaining broad up-market acceptance. SalesForce.com probably fits into this category and warrants a little attention:

SalesForce.com’s magic in moving into the top-end of the market has shades of the iPod phenom to it. With SalesForce.com and the iPod, people willingly trade away advanced features and fine-grained control for cachet/buzz. In the case of SalesForce.com, up-market clients are willingly throwing out custom-tailored sales-force automation and rearrange themselves to fit into the SalesForce.com mold.

I can’t say exactly why, but I think part of this comes from providing APIs. APIs don’t have the murkiness of customizing workflows; APIs tend to deal with the models/transactions directly; the workflow becomes the responsibility of the customer who uses the API.

I think the take away from this is that if your maintenance revenues can’t justify workflow customization that you should look for ways to adapt your application to be more transactional so that you can places where APIs are a natural fit.

An example of this from the SalesForce.com world is how they slurp leads into their system — the source of the lead, how it was gathered (the workflow), etc. is all left as an exercise to the customer. They don’t care how you got the lead — website, tradeshow, pulling business cards out of the burrito giveaway fishbowl at Chipotle — but they’re only too happy to take it into their system.

Needless to say, APIs bring complexity for your customers, but it you’re competing-with/replacing what would otherwise be installed software in the middle market or higher, your customer is likely to have a CIO who is well equipped to deal with these things. And, again, the low and lower-middle markets won’t expect much customization, so your good-enough one-size-fits-all workflow will probably be good enough.

In summary, decide which kind of business you’re in and don’t lose track of how that impacts “the four criteria.”

Posted in Uncategorized | Comments Off

Pay It Forward / Not Zero Sum

October 3rd, 2007

When a community makes an investment in you and, as a result, good things come to you then you have an moral obligation to feed back into the community that supported you.

This evening, at an informal meeting of tech entrepreneurs, I witnessed a counter example of this pay-it-forward principle that really took the wind from my sails.

One of the attendees, the founder of a local startup, sat down and informed me that he was, “sitting on a bunch of investor money.”

Over the last year this guy has taken all the free help available in town. Attorneys, executives, founders of other tech companies, branding people, developers, marketing people, rainmakers, mentoring, speaking spots are events, the works.

On top of that, he’s been teaching MBA students and — get this! — he has them write business plans for his startup. He credits the MBAs with developing business plans beyond what he could have thought of on his own. I appreciate the hutzpah, actually, but read on.

Our entrepreneur had been working to raise money for a while and I was pleased to hear of his success, particularly given that his company is based here in Minneapolis/St. Paul. I spent 6 years in San Francisco because it was so much easier to raise money there; my immediate reaction to his success was, “This is great, how can we duplicate it?”

Whenever someone raises money, and more to the point when they go out of their way to tell you that they raised money, the next two questions are, “How much?” and “From whom?” Those are universal. It’s part of the social contract. It’s expected. It’s even encouraged. When someone makes an investment in you, you share a mutual pride; you’re standing together, planting a flag and saying, “We mean to make something special here.”

He responded to the how-much question with a sizable figure. You will, however, understand my reaction — flabbergasted! — when he stonewalled on the from-who question with, “I’m not saying.”

Me, “What? You’re not saying?”

Him, “I’m not saying.”

Me, “Why on earth not?”

Him, “I’m not saying.”

Me, “You’re kidding, right? <Name>, it’s not like a lot of deals are getting done here. We need to feed the ecosystem, to duplicate this success.”

Him, “I’m not saying.”

Me, “Are you worried they’re going to take the money back? That they’ll be inundated with deal offers? What?”

Him, “I’m not saying.”

At this point continuing the transcript reaches the point of diminishing returns. We’d entered a conversational black-hole from which nothing could emerge. I did tell him that I thought that he was acting stupidly. You can fill in the rest yourself.

The whole conversation stung. Here’s a guy who had taken all that was offered, gained from it, and flatly refused to close the loop. The arrogance of this guy taking on a “gatekeeper” role floors me.

This position might be understandable if it was somehow “value-maximizing,” but it’s not. First, this isn’t a zero sum game. Second, Robert Axelrod’s “The Evolution of Cooperation”, demonstrates that your best course of action when deciding whether to (a) do good by someone or (b) screw them is to give them the benefit of the doubt in your first interaction and then to play “tit-for-tat” with them. If they’re good to you, you do good to them. If they’re bad to you, you do bad to them. This guy’s actions have put him into the “bad” camp, so he deserves to be screwed.

Posted in Uncategorized | Comments Off

Dan Grigsby

40 Under 40

RubyFringe: Us: The Sex Pistols. Them: Kenny G.

The Tyranny of CSS And Ajax, A Timex Watch And A Barrel Full of Rocks

A Plan For Minnesota

Repeatable Pattern

Larger Pattern

India Looked Good On Paper

Enter Minnesota

Sweet Suite Spot

Definition Disconnect / Two Kinds of “Software As A Service”

Pay It Forward / Not Zero Sum

Archives

Speaking At

Teaching

Meta