« May 2007 | Main | July 2007 »

June 2007

June 30, 2007

Quick Review - Easy (and Legal) way to share iTunes

This is off topic for this blog, but I have been using a beta tool from  Simplify Media that is pretty cool, and I wanted to mention it.  Simplify has just come out of stealth mode, so I assume it is open season for blogging now.

Their tool lets you make your iTunes library available to others: other machines you own (such as laptop accessing desktop), other people in your family, or friends across the Internet.  Your library (or at least the part of it you decide to publish) is displayed in a very natural way in the other machines iTunes UI, it is just another icon over on the left, like the local library or the various playlists.  You can click on the icon you see the songs listed you can doubleclick on any of them to have it start playing as a stream across the network.  None of those songs are permanently stored on your disk, so they don't take up space and you don't have the RIAA suing you.

ITunes has some native ability to do this within your local network,  but the Simplify tool is the better option.  For example, it can go across the Internet not just the local network, which is much more useful.  By worrying only about sharing Simplify can do more than what will be built into iTunes.  They can work across iTunes, Winamp, Windows Media Player, etc.  They are constrained just be the legal limits, not by policies defined in record company deals cut by Apple.

On the downside one issue is that they did not have a Vista version at the time I did my install a month ago.  They claimed to have one coming soon, so they may have it posted for download by now.

On the upside it was very easy to install to give it a try.  The do show ads (hey everyone has got to make a living), but their privacy policy seems strong and they have a peer-to-peer approach that limits what info is sent back to their servers - they are clearly not spyware.

If you want to give it a try the download is here.


June 16, 2007

Leverage

To quickly generate dramatic growth in usage ventures need to use "leverage" to their advantage.

Startups that have a credible potential to be sold or go public for a 10x gain on invested capital within 4 to 6 years of the date of funding should consider raising venture capital.

Most other startups should not raise venture capital. This includes: ... startups where there's no inherent leverage in the business model that could result in a 10x gain in 4 to 6 years ...

Notably, there are many fine businesses in the world -- many of them highly profitable, and very satisfying to run -- that do not have leverage in their model that makes them suitable for venture capital investment.

By leverage in this context, I mean: the ability to make something once (a piece of software, a chip design, a web site) and sell it (directly or indirectly) to a lot of people (1,000 business customers or 10 million consumers) -- which leads to the classic "hockey stick" revenue projection.

While the above is acknowledged as true in the abstract, in practice actual startups often lose sight of this point and create patterns where there is not enough leverage.

Here is one typical software venture scenario:

  • Start-up with no revenue and no market presence feels intense pressure to land some key large customers to establish their credibility and prove the value of their business proposition.
       
  • Those initial large customers are hesitant to work with a small unproven company.  The start-up responds by saying "we may be small, but that is an advantage as we can be nimble and quickly deliver to you a product/service that exactly matches your specific individual requirements"
       
  • This pitch succeeds and lands some important initial customers.  Because they see something working (after a long period of struggling) the sales team repeats the same pitch to other potential customers.
       
  • Under pressure to move quickly the software team does not build a configurable platform but rather does customer-specific source modifications to the core product to deliver on what each customer expects.  Which leads to multiple source branches, high maintenance cost.  low ability to deploy new features across all customers, high incremental costs per each new customer, etc.

The above scenario is common and can lead directly to falling into a low leverage trap.

There are absolutely times when doing a low leverage special feature for a specific launch customer is the right thing to do.  The question is, do you want this to be a rare exception or is it a pattern you want to replicate?

Here are two models:

  1. .“On-demand individualized customer service" model focused on directly  responding to unique needs of large customers, through a negotiated delivery plan.  “Professional services” companies such as IBM Global Services and Infosys fit this model.  As does a large part of the Defense industry: companies such as SAIC.
       
    B.
  2. "Market service" model focused on executing roadmap that delivers high leverage: creating a single unified service/product that meets the needs of the broad market. Examples here include: eBay, Amazon, Google, Adobe, and Microsoft.

Successful businesses can be built using either model.  However, the "market service" model has higher leverage, higher valuations, and greater probability of leading to fundamental changes to how we work and live. 

If you have the opportunity to pursue this "market service" model you should clearly do so, even if it means extra effort and extra risk.

If your business does not lend itself to pursuing the "market service" model that is ok too, you can build a good business creating custom solutions for large customers.  However, that approach will mean slower growth than a successfull "market service" model and you need to make sure your team and investors understand that.

The one thing that absolutely does not work is to be mis-aligned:  you claim you are aimed at one of the models and some of your activities reflect that, but a large part of your actual behavior fits the other model the one you are not targeting.  This is a recipe for painful failure.

Committing to building a high leverage model takes real discipline: the engineering team has to avoid taking tempting (but non-scalable) shortcuts, the sales team will sometimes need to pass on a customer which goes against all instincts.  However, if you can recognize the difference between urgent and important, and instill that self-discipline you will be well rewarded.

                                                                               copyright 2007 Kerry Champion

Quote - If you don't like ...

 

If you don't like something, change it.  If you can't change it, change your attitude.  No matter what, don't complain. - Maya Angelou

   

June 05, 2007

Surveillance and diligence

As I mentioned in a previous post I recently heard Atul Gawande talk about his book "BETTER: A Surgeon’s Notes on Performance".  He made observations about why some teams have much better results (in terms of patient medical outcomes) than others.

He highlighted two traits that seemed to be central to that success: "surveillance" and "diligence".  These traits are incredibly important in the software world as well, for much the same reasons as touched on by Atul.

I am not sure that "surveillance" is the best possible phrase to use, I prefer to think in terms of "active observation."  Whatever the label the concept is critical.  Here are some points to keep in mind when practicing active observation:

  • Don't depend solely on your own observations, enlist the broader team to take part in the process and listen carefully when they share what they are seeing.
     
  • Don't accept everything you hear at face value, question and probe, search for validating or contradictory data points.
     
  • Make sure you have a good consistent data set that lets you make comparisons over time and comparisons between different people and different projects.  When there is variation in that data set probe into it, even if the variation seems small.
     
  • Take advantage of your insights into well known patterns of misleading reports.  Some folks are modest and pessimistic and consistently make things sound worse than they are.  Others may tend towards self-justification.  In any case you need to look for these patterns and take them into account as you get new reports from the same source.
     
  • As you form conclusions based on these observations, test that conclusion, make predictions based on that conclusion and go look at the relevant data.  If your new data points don't support your prediction, than your conclusions are probably wrong.

Atul makes some key points regarding "diligence":

  • Diligence can be defined as "the constant and earnest effort to accomplish what is undertaken."
     
  • "People underestimate the importance of diligence as a virtue" perhaps because on the surface it sounds mundane and simplistic.
       
  • However, diligence is a "prerequisite of great accomplishment" and "one of the most difficult challenges facing any group of people who take on tasks of risk and consequence"

I agree wholeheartedly with these points and would add just a couple more regarding the practice of diligence. 

  • It is unreasonable to expect diligence from someone who does not understand why their tasks matter in the bigger scheme of things.
       
  • Having relevant and easy to understand metrics that are shared with the entire team, encourages diligence and continuous improvement.
       
  • Developing team practices that enable folks to get into a good rhythm and spend most of their time "in the zone" is critical to encouraging diligence.  There are lots of things (too many meetings, unproductive meetings, inconsistent goals/feedback, constantly switching assignments, etc.) that will pull folks out of the productive zone and discourage them from trying.
     
  • An out-of-context or irrelevant response to anxiety or social tension is called a displacement behavior.   I believe this term was originally from animal behavior studies, but it certainly applies to humans as well.  For example you may feel anxious about a deadline, doing the relevant work just reminds you of how hard it will be to make the deadline, which makes you even more anxious, so you find yourself reading Slashdot or reorganizing the source tree instead of actually working on the relevant implementation.  Team leaders need to give folks an open door and when they express anxiety or point out tension, leaders need to help them work-around those issues so they can pursue the tasks that matter instead of getting sucked into an eddy.   

Here is Atul's description of a Doctor who has mastered the arts of surveillance and diligence.  This describes an examination of a Cystic Fibrosis patient (Janelle) by her Doctor (Warwick).  Even though the specifics of this situation are far from the specifics of a software project, the mindset and basic skills shown here are extremely relevant.

Warwick pulled out her latest lung-function measurements. There’d been a slight dip, ... Three months earlier, Janelle had been at a hundred and nine per cent (she was actually doing better than normal); now she was at around ninety per cent. Ninety per cent was still pretty good, and some ups and downs in the numbers are to be expected. But this was not the way Warwick saw the results.

He knitted his eyebrows. “Why did they go down?” he asked.

Janelle shrugged.

Any cough lately? No. Colds? No. Fevers? No. Was she sure she’d been taking her treatments regularly? Yes, of course. Every day? Yes. Did she ever miss treatments? Sure. Everyone does once in a while. How often is once in a while?

Then, slowly, Warwick got a different story out of her: in the past few months, it turned out, she’d barely been taking her treatments at all.

He pressed on. “Why aren’t you taking your treatments?” He appeared neither surprised nor angry. He seemed genuinely curious, as if he’d never run across this interesting situation before.

“I don’t know.”

He kept pushing. “What keeps you from doing your treatments?”

“I don’t know.”

“Up here”—he pointed at his own head—“what’s going on?”

I dont know,” she said.

He paused for a moment. And then he began speaking to me, taking a new tack. “The thing about patients with CF is that they’re good scientists,” he said. “They always experiment. We have to help them interpret what they experience as they experiment. So they stop doing their treatments. And what happens? They don’t get sick. Therefore, they conclude, Dr. Warwick is nuts.”

“Let’s look at the numbers,” he said to me, ignoring Janelle. He went to a little blackboard he had on the wall. It appeared to be well used. “A person’s daily risk of getting a bad lung illness with CF is 0.5 per cent.” He wrote the number down. Janelle rolled her eyes. She began tapping her foot. “The daily risk of getting a bad lung illness with CF plus treatment is 0.05 per cent,” he went on, and he wrote that number down. “So when you experiment you’re looking at the difference between a 99.95-per-cent chance of staying well and a 99.5-per-cent chance of staying well. Seems hardly any difference, right? On any given day, you have basically a one-hundred-per-cent chance of being well. But”—he paused and took a step toward me—“it is a big difference.” He chalked out the calculations. “Sum it up over a year, and it is the difference between an eighty-three-per-cent chance of making it through 2004 without getting sick and only a sixteen-per-cent chance.”

He turned to Janelle. “How do you stay well all your life? How do you become a geriatric patient?” he asked her. Her foot finally stopped tapping. “I can’t promise you anything. I can only tell you the odds.”

In this short speech was the core of Warwick’s world view. He believed that excellence came from seeing, on a daily basis, the difference between being 99.5-per-cent successful and being 99.95-per-cent successful. Many activities are like that, of course: catching fly balls, manufacturing microchips, delivering overnight packages. Medicine’s only distinction is that lives are lost in those slim margins.

And so he went to work on finding that margin for Janelle. Eventually, he figured out that she had a new boyfriend. She had a new job, too, and was working nights. The boyfriend had his own apartment, and she was either there or at a friend’s house most of the time, so she rarely made it home to take her treatments. At school, new rules required her to go to the school nurse for each dose of medicine during the day. So she skipped going. “It’s such a pain,” she said. He learned that there were some medicines she took and some she didn’t. One she took because it was the only thing that she felt actually made a difference. She took her vitamins, too. (“Why your vitamins?” “Because they’re cool.”) The rest she ignored.

Warwick proposed a deal. Janelle would go home for a breathing treatment every day after school, and get her best friend to hold her to it. She’d also keep key medications in her bag or her pocket at school and take them on her own. (“The nurse won’t let me.” “Don’t tell her,” he said, and deftly turned taking care of herself into an act of rebellion.) So far, Janelle was O.K. with this. But there was one other thing, he said: she’d have to come to the hospital for a few days of therapy to recover the lost ground. She stared at him.

“Today?”

“Yes, today.”

“How about tomorrow?”

“We’ve failed, Janelle,” he said. “It’s important to acknowledge when we’ve failed.”

With that, she began to cry.

Warwick’s combination of focus, aggressiveness, and inventiveness is what makes him extraordinary. He thinks hard about his patients, he pushes them, and he does not hesitate to improvise.

I particularly appreciate the comment "... combination of focus, aggressiveness, and inventiveness is what makes him extraordinary"  That certainly applies to the software world as well.

                                                                               copyright 2007 Kerry Champion

April 2008

Sun Mon Tue Wed Thu Fri Sat
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30      
Blog powered by TypePad