Category Archives: Uncategorized

Once in a while, I bump into some good-sounding advice from an entrepreneur who built a successful business. For example, I recently reencountered an old post by HubSpot CTO and Founder, Dharmesh Shah, titled Failure Is Not The Worst Outcome, Mediocrity Is (which spurred debate back then). Or, I recently read an interview with an entrepreneur arguing why employees’ after-hours activities are important to a company’s success.

In the last few months, since I left my full-time position at Webcollage (and our acquirer, Answers), I’ve had the opportunity to work with many entrepreneurs and early-stage companies — both business-to-business (B2B) and business-to-consumer (B2C).

While B2B and B2C ventures share several areas of commonality (company and leadership values come to mind), it is interesting to notice deep areas commonly different between the two: all the way from the business perspective to the (somewhat surprisingly) technology perspective.

The recent write-up by Michael Eisenberg at Aleph VC highlights one of the key differences and eloquently explains why in many cases the product matters more in B2B companies. The write-up is written from the viewpoint of an Israeli VC (and hence references challenges in hiring B2B/SaaS executives) but the merit of the write-up is agnostic to geography.

In the last few days the acquisition of WhatsApp for a stunning sum of $19b was the most popular discussion topic in the tech business community.

The reaction to the acquisition cost ranged from criticism (like this Tumblr post suggesting that Iceland may be cheaper, at $14b) to thoughtful analysis of the economic value of WhatApp’s 450 million users (like this CNN Money article) or its SMS volume.

On Dec. 5 I plan to deliver a talk on managing product requirements in an agile environment. The talk is planned to cover practical aspects and discuss how we (at Webcollage) manage product requirements and product launch while delivering new software releases to Fortune 500 clients every two weeks. If you’re interested this topic, feel free to come over – take a look here: http://www.productexcellence.co.il/.

Whereas modern product cycles rely on shorter cycles, something along the lines of this diagram:

The assumption in modern approaches is that the road to good software is shorter when making smaller steps and frequent turns than when making large steps and more radical turns. (This is geometrically true in the diagrams…)

Old-style product cycles consisted of three main steps: planning (negotiation, prioritization, scheduling), development (design, coding, testing) and launch (alpha/beta, release, outbound marketing). The main question I was trying to tackle in the talk was how the corresponding activities map to product cycles with frequent releases.

On a side note, some organizations use old-style product cycles (infrequent software releases) while using “agile development” techniques internally (that is, frequent internal releases). While perhaps better than nothing at all, this approach misses—in my mind—much of the benefit in agile software development. In the end of the day, the biggest benefit is adapting to customer feedback, and without the software reaching real customers, value diminishes.

The areas I was trying to tackle in the talk were:

How does planning occur in an environment when there’s no defined period for planning (“beginning of the release”)? When the working assumption is that many of the details (and associated effort) will be revealed during the development process. And, how do roadmaps look in such an environment?

How do product launches occur in an environment when there’s no defined period for launch, but—instead—software is ready in chunks? How and when does customer feedback get incorporated into the cycle?

How does one integrate new approaches and opportunities brought about by agile development? Mostly, agile approaches facilitate experimentation through proof-of-concepts and such (with various variants such as MVP, MSP, and lean).

Last week I attended a conference kindly organized by Outbrain, a start-up company located in Netanya, Israel. Outbrain’s VP R&D, Itai Hochman, described their engineering philosophy, which includes—among other things—avoiding “broken windows”. The Broken Windows Theory (popularized by the decline of crime in New York in the 1990’s) suggests that having broken windows in a neighborhood quickly escalates into more severe crime. The engineering analogy would be that unattended “issues” in the product would similarly result in more global deterioration of quality.

The broken windows metaphor is appealing. But, a metaphor from the economics world—that of a debt—may provide a few more tools to handle product gaps.

In many parts of the world, it is common to take loans to finance large purchases, such as a house or car. Interestingly, most people can typically pretty easily understand the concept of a loan, or debt. There’s the net cost of what you want to buy (say $100,000). Rather than paying the net cost upfront, one pays some down payment (say $20,000), and then pays back the remaining portion in installments over a period of time (say $2,000 monthly). The eventual sum paid incorporates some interest, which means that the overall price paid is higher than the net price. Most people get the concept, and can even handle the math with some basic calculators.

What’s interesting is that when creating software, a similar phenomenon occurs. And, as the recent economic meltdown has proven, taking more debt than one can afford can have a detrimental effect.