My son just conducted the Melbourne Symphony Orchestra!

This morning our family went to a Classic Kids concert given by the Melbourne Symphony Orchestra. Lots of fun music and dancing and learning about the instruments and sections of the orchestra. The different sections were dressed in different colored tops to aid identification, a la the Wiggles, and the conductor had a multi-colored top on.

The MSO, in more formal attire

A boy and girl were selected to conduct The Liberty Bell, and my kids, who were seated at the front were predictably disappointed not to be picked. But wait ...

After kicking off the finale, The William Tell Overture ("Hi ho Silver - away!"), one of the most thrilling showpieces in the orchestral repertoire, the conductor, Ben -- Benjamin Northey, bless him, may he have a long life and outstanding career -- dashed into the audience, asked Jake's Mum if he'd like to conduct (swift affirmative response), and led Jake to the podium where he handed Jake the baton. Jake proceeded to perform with verve, enthusiasm and undisguised joy for about 3 minutes, all the way to the end of the finale, followed by wild applause from the audience.

Benjamin Northey, my favorite conductor

It was awesome. I was in tears, Andi (Jake's mum was in tears), and Ella no doubt expects to get to conduct the orchestra next time round. It was awesome and inspiring. A child came up to Jake afterwards and said that he was better than the real conductor; that kid will not grow up to be a music critic, but bless him too!

On questioning Jake said that the fast bits were more challenging to conduct than the slow bits, and that even though conducting was fun, he would prefer to be an inventor of new musical instruments when he grows up than an orchestra conductor.

Jake played Moses at kindergarten (with stick), and conducted the MSO at age 5 in the William Tell Overture with baton. What a little legend!

Andi's post on the same incident.

Update: Andi wrote to Benjamin Northey to thank him. Here's his reply:

From: Benjamin Northey
Sent: Sunday, 22 November 2009 11:32 AM
To: Andi Herman
Subject: Re: Thank you

Hi Andi,

So kind of you to share this with me. Jake was pretty much the highlight of the week for us! The orchestra loved him and as you say, to see such pure joy was very special indeed - very moving. Loved reading the blogs also.

I hope that this is something Jake will remember for a long time. Please say hi to BOTH of your children from me!

all best, Ben

We hope so too. Thanks again, Ben.

So he writes books about movies?

From the "Overheard" section in mX:

Girl: I'm going to see Taming of the Shrew.

Friend: Is that like the book that's based on the movie Ten Things I Hate About You?

Girl: Not quite. It's by William Shakespeare.

Friend: Didn't he do Romeo and Juliet?

Girl: That's the one.

Friend: So he writes books about movies?

Girl: Have you ever been to English class?

Classic.

Opposite rhymes

My daughter Ella, who is not yet four, has invented a new word game called "opposite rhymes".

You know how the word game "opposite pairs" works: Name pairs of words that are opposites. For example:

• Big - little
• Black - white
• Hot - cold

And "rhyming pairs":

• Fiddle - middle
• Hot - cot
• Head - said

But in opposite rhymes (also known as rhyming opposites) you have to do both at once, making it considerably harder:

1. Ella: Tall - small
2. Andi: Happy - crappy
3. Andi: Sad - glad
4. Dan: Familiar - unfamiliar (deemed unacceptable)

So I'm pretty impressed with my little girl for inventing this new form of wordplay and finding the first one.

Can you find of any others? It ain't easy.

Which religion should I follow?

Gone are the days when one simply followed the religion of one's forefathers and foremothers. For those who find themselves confused by all the different choices on the market, here's a handy visual guide:

Click for a larger and clearer version

Hopefully people of all faiths and non-faiths are equally offended and amused.

Promoted - again!

It seems to be the season. Around this time last year I was promoted to CTO, and this time round, my boss has decided to move on, and I have stepped up to the hot seat of CEO-dom.

All of this has been bad for my Kibitz blogging, although I have been contributing to a new blog all about our emerging visual collaboration product: bCisive Online:

A diagram quickly knocked up in bCisive Online - click to enlarge

Divide and conquer meets visual thinking meets true real-time collaboration. Interested? Check it out, and get in touch.

That said, I'll try and post the occasional kibitz or update here too.

bSelling from the Top Down (and bottom up)

When we first developed bSelling Opportunity Management Software we had a choice: Focus on bottom-up or top-down issues.

We chose bottom-up first: Make the software easy and fun to use, and useful to the individual sales rep.

Almost immediately, our early adopters made us very aware that as much as they loved what we already had, there were burning top-down issues that needed to be addressed asap:

1. How can the sales manager get an effective overview of all open opportunities?  And then drill down.
   
2. Similarly, how can an individual salesperson get perspective of all his opportunities in order to better gauge where and how to focus effort?
3. How can a sales manager customize the qualification process to fit her team's needs?
4. How can a sales person or manager share insights with other team members, or present a pitch to clients?

We listened and have carefully crafted some exciting new features, again blending visual flair with smart functionality:

Better overviews: The bSelling Opportunity Explorer

The bSelling Opportunity Explorer is a new dashboard that shows every open Opportunity and positions it graphically based on its qualification percentage -- the likelihood of success as determined through the bSelling flip-card based Qualify tool -- and the expected Amount in $ from a successful close:

Click to view a larger image

The size of the bubble shows how much effort the rep. has been devoting to the opportunity.  Hovering on an opportunity identifies it and gives precise numbers.  Clicking opens up bSelling for that opportunity.

Overview

Looking at the overall distribution gives an at-a-glance overview of where all opportunities are at, and where the effort is going.  The four quadrants are labelled to assist interpretation:

1. Excellent: The upper right contains the best-qualified, highest amount opportunities
2. Safe bets: The lower right are well qualified, lower amount opps
3. Pie in the sky: The upper left contain the high amount, not yet well qualified opps
4. Poor: The lower left contains poorly qualified, low yield opps

Reading the patterns

With very little practice, certain patterns should start to leap out as meaningful:

• In the image above the line of small circles on the vertical axis are unqualified opportunities.  Why haven't they been qualified yet?
  
• Large circles in the left quadrants reflect opportunities where a lot of effort is going in without much progress.  Some of the "pies in the sky" may be worth persisting with (for a while), but the "poor" opps need to be quickly qualified across or dropped.

For the individual salesperson this overview can be a powerful tool to help manage his pipeline.  For the manager, it allows her to see how the team as a whole is performing, and focus action where needed.

Customization: Tailoring the process

The bSelling Qualify Tool adds rigor and guidance to qualification by asking the salesperson to flip through virtual card-decks that rate all the important factors associated with an opportunity.

It is now possible with bSelling premium to customize this standardized tool across a team or organization to meet a preferred methodology or to cater to specialized needs:

And here's an in-depth overview.

Sharing: Exporting to PowerPoint

Sales and account managers often need to report on key opportunities to executives and other non-sales colleagues.  To illustrate their understanding of an opportunity and to help their audience understand the client contacts' perspectives, bSelling premium now includes a convenient "export to PowerPoint" facility in the Diagnose Pain tool.

When pitching to a customer, diagrams prepared in Present & Sell can be turned into a sequence of PowerPoint slides in the same way.

Conclusion

bSelling remains fun and friendly, but has grown more power-packed.  

It blends bottom-up advantages (usefulness, simplicity, fun) with top-down virtues (overview, customizability) and communication (visualization, PowerPoint export).

We'll keep refining it, and can also further customize to meet more specialized needs.

Fartlek development

The amusingly named Fartlek training is a form of athletic training in which high intensity work and low intensity work are alternated in the course of each training session. The two forms of work are complimentary in that they stress the you in different ways (anaerobic and aerobically) and allow you a chance to recover.

I think that this is a good model for software development in software start-ups.

Priority one: Build something that people want, fast

The main risk in a software start-up is making something that people don't want. So you want to find out whether your initial idea has merit, fast. So -- if at all possible -- you build a small prototype, and test it out in the marketplace, fast.

In order to satisfy the need for speed, you cut a few corners, and because it's small (and your team is good) you can get away with this approach (for now).

If no-one wants your prototype, you scrap it, and you haven't wasted time on lots of process that was supposed to pay off in the long-run (because there is no long-run).

On the other hand, if it the prototype is promising, you will learn from the market feedback how to make it better, and it will start to grow. This is where it is critical to switch gears and slow down (at least for a while). Because if you do not, you will find yourself in the realm of cowboy development, the bugs will start to bite, and the pace of development will drop as your team gradually spends more and more time debugging, less time developing, resulting in a drop of confidence -- "I don't want to quickly make this change because it might break something" -- and loss of tempo.

Priority two: Restore quality (and sanity)

The alternative is to switch modes. Fred Brooks said "build one to throw away", but at a minimum you should review what has been done to date and investigate and prioritize the very real risks of continuing with a prototype. These might well include:

1. Customer or prospective customer loses data or has it corrupted
2. Customer or prospective customer experiences bugs, crashes, or loss of service
3. A crash or a bug during a demo
4. The software does not scale, so performance degrades over time
5. Development slows so that critical new features can not be delivered in a timely fashion

Improving the quality of the software process is what is needed for most of these, and many of the kinds of measures that help have largely been formalized in the Agile development processes:

• Pair programming: Two heads are better than one, plus it offers real time code reviews, mentoring, camaraderie and friendly competition, less web-surfing
• Test-driven development: Writing automated tests clarifies the design and as they build up offer an early warning system when a change breaks something unexpectedly (Design by Contract gives similar benefits)
  
• Continuous integration: Frequently "checking-in" and automatically running the automated test-suite identifies incompatible changes made by different programmers or pairs sooner rather than later; saves you from merge hell
• Refactoring: By reviewing code, eliminating duplication, reducing coupling, and improving the use of abstraction, your software base will become more concise, readable and maintainable
  
• Short iterations / planning game: By maintaining a list of feature requests and bug-fixes that the developers estimate and the internal customer prioritizes (within a budget based on the amount of work accomplished in the previous iteration), a sustainable rhythm is established, and healthy prioritization is forced
  
• Sustainable pace: Working more than an eight hour day / forty-hour week leads rapidly to damaging the code base, loss of morale, and bull sessions as people are present in body, but not in spirit -- avoid the "Death march" scenario
  

Additionally, a design review will be needed to knock the existing architecture and code into shape, and tests will needed to be added retrospectively if you didn't practice test-driven development in the initial prototype phase.

For a web-based service additional infrastructural elements and diagnostics should be reviewed and added.

All of this is manageable as long as the prototype is small, but the longer these steps are delayed, the greater the costs that must be paid. It's a lot like going into debt. You not only have to repay the loan, but also the accumulated interest. Some people call this design debt. (And the interest rates on design debt tend to be high.)

And then the cycle turns

While making incremental changes continued agile iterations is probably the way to go, slow and steady (but not slowing down). When the time comes to make a leap forward, knocking up a quick prototype is a great way to vary the routine, and makes business sense.

Conclusion
Almost everyone who learns to program first experiences the joys of "cowboy development" on small personal projects, but when they "turn pro" or start working on larger projects they soon learn that it doesn't scale beyond what you can easily hold in your head.

Some people think that up-front design and analysis will save the day, but this leads to waterfall with its 1/3 design, 1/3 development, 1/3 testing rule-of-thumb when done well. But then you discover that the requirements were wrong (they always are), and another long iteration is required.

Smart people rediscover short iterations, and lately these have been articulated as Agile Methods, and also include other ways to make the computer (e.g. automated tests) and human nature (e.g. pair programming) work effectively and more satisfactorily. The cost is a bit of deferred gratification by having to do some things up front (e.g. writing tests, refactoring) that pay off over time.

However, it would be wrong to say that an Agile approach is the best for everything, at every scale. In particular, in knocking up a quick prototype one may well be justified in reverting to some of the cowboy practices for a short period. Note that it is not compulsory to drop all the agile practices when doing so -- do what suits the situation.

The tricky bits are:

1. Not leaving it too long
2. Paying off the accumulated technical debt
3. Getting back into the discipline of following the practices
4. Combating the likely organizational pressure to continue at the previous pace!

So good luck with the fartlek development*, and let me know what you think.


*My esteemed colleague -- and former Olympian -- Ben Loft points out that interval training may offer a better analogy, but the name isn't as memorable.

Provocation-based Selling (and Provocative Writing)

Who doesn't love a controversy?  Want to get noticed?  Provoke!  Capture attention!

The trick is to follow up with something that hits the spot lest you alienate your suddenly alert audience.

One way to provoke attention is to insult a big-name.  In a recent article in the Harvard Business Review -- In a Downturn, Provoke Your Customers -- the authors (including Geoffrey "Crossing the Chasm" Moore) slam the generic notions of consultative selling and especially solution selling (as opposed to the more specific Consultative Selling and Solution Selling®) either through ignorance or in a straightforward grab for attention.

The only problem -- as Keith Eades, CEO of SPI correctly points out --  is that they have done so to a large extent by over-simplifying Solution Selling,  and  then  comparing their "new" approach to a whittled down husk: 

Whereas solution-selling salespeople listen for “pain points” that the customer can clearly articulate, provocation works best when it outlines a problem that the customer is experiencing but has not yet put a name to. -- from the article

But Solutions Selling has a powerful way to think about where your customer is at, before getting into "pain points":  Levels of Need*: 

1. Latent need: Unaware of a need that could be satisfied by purchase (perhaps they are unaware that there's a problem, or in denial, or resigned to coping with the status quo)
2. In pain: Aware of the need ("in pain"), but unaware of how your offering can help
3. Vision creation: The prospect has a vision or a "Solution", ideally including your offering. 

A key part of Solutions Selling is to move the customer upward through these Levels of Need.  The article mis-characterizes Solution Selling as simply asking the prospect about their pain (i.e. jumping in at level 2 - In pain), while correctly pointing out that during a downturn many more people will tend to be at level 1 because they are doing their best to make-do with much-reduced budgets and discretionary funds.

A key part of "provocation-based selling" seems to be to provoke a response by forcefully articulating a problem that the customer has, get them to acknowledge it, and then make a bee-line to the person who has the authority to do something about it (and who can release funds to purchase).

This is all good Solution Selling, just in slightly different terms.  In classic Solution Selling one would first try to stimulate the interest of a contact with a Reference Story, typically describing a person in a similar situation to their current one and how you were able to help that person.  Hopefully the contact will respond by either confirming that (s)he has similar issues, or -- equally good -- say something like, "No, we don't have those problems.  This is what's really bugging me ...".  Either way, you are engaging and on your way to level 2.  While exploring the prospect's pain, you should also be finding out who else is affected (i.e. who else you need to speak to get a fuller organizational picture of the pains, and also who can authorize a sale), etc.   [I have a fuller summary of Solution Selling here.]

The authors of the HBR article have a good point to make: That during a downturn a forceful -- or provocative -- approach may be a good way to jolt prospects into thinking about what can be done to improve their business, including alerting them to problems that they may be reluctant to address.  They suggest a mixture of fear -- "if you don't do something you're doomed" -- and hope -- "but we can help you get through this".  This seems like a good approach, provided you have accurate information, and can pull it off without alienating your prospect by coming across as arrogant: "I know your problems better than you"!

So "props" to the authors of In a Downturn, ... for being provocative, and thereby garnering some attention for the important issue of jolting people out of latency during a downturn.

My guess is that the authors feigned ignorance of Solution Selling etc. to whip up controversy, and that's probably a good thing!

* Austhink's add-on to SalesForce crm -- bSelling Opportunity Management -- augments SalesForce's contact information (which is a bit more Miller-Heiman-esque out-of-the-box) with a Level of Need field.  Naturally, we also do pain points!

To Customize is Cool

It's cool to customize! It practically has the word "customer" in it, so what's not to love?

Seriously: When prospective customers see the Qualify tool -- part of Austhink's bSelling add-on to Salesforce crm ...


they say two things:

1. Wow!
2. Can I customize it?

The "Wow!" reaction is because here is a tool that really helps the salesperson with a vital but difficult task -- sales qualification -- in a fun way. It provides useful feedback -- an overall percentage, and sensible concrete ways to boost the score. Ok: Most of the wow is because of the fun factor and groovy way it plays (like flipping through photos on a Mac).

The second reaction -- the wish for customization -- is natural. Although at Austhink we believe that the out-of-the-box system is quite generic, sales teams do of course vary in their terminology, types of customers, and overall slant sales.

So, I recommend a suck it before you salt it approach:

1. Try out the generic version (that comes with the free version of bSelling) on a few opportunities to get the feel for the process. Just pick a neutral "card" if a factor doesn't seem to apply.
   
2. Make notes about where the terminology needs revision, which "factors" don't apply, and which (if any) are missing.
3. Upgrade to the premium version of bSelling and make use of our soon-to-be-released customize feature.
4. If you need extra help, we can arrange consultation!
   

The customize feature allows your company to change the wording, options, factors, and weightings -- i.e. everything -- of the Qualify tool to tailor it to fit your unique situation. Just like the tool itself, it looks great, is fun-to-use and it has a game-like feel. Here's a sneak peak:


Each line represents a deck of cards in the tool, and each block represents a single card. The length of each line represents the weight of each factor. You just click on a box to edit some wording (shown), or click on an end box to stretch or squash a line (to make a factor more or less important compared to the others). Other operations are similarly simple.

By the way: If you think of the Qualify tool as a level in a game, the customization tool is like the level-designer that allows an obsessed user to design new game levels for their friends to play. In this case, the customization tool allows the sales-manager to tweak (or totally revamp) the qualification process to fit local conditions, and better monitor (and mentor) the sales team.

We are about to trial the customization tool with a select group of beta-testers -- email me at dan@austhink.com if you want to give it a whirl -- and the first version should be available in the next week or so.

From Moses to Moses ...

"From Moses to Moses there was none like Moses". The two Moses's of the quote are Moses the lawgiver -- he 0f the 10 commandments etc. -- and Moses Maimonedes the greatest Jewish sage of the middle ages.

Loyal readers of this blog will remember that last year my son Jake portrayed the earlier Moses in the kindergarten Pesach (Passover) play:

Jake as Moses

Witnesses said that his manner and physical resemblance to the biblical Moses was uncanny, and it seemed it would be a long time before anyone would else would pull off such a convincing portrayal ...

That was until Jake's little sister Ella put on the beard!

Ella as Moses

Apparently Ella was a little more tentative in her portrayal than Jake had been, but she is a year younger than he was when he took on the role.

Nevertheless, I am again very proud indeed. (And amused.)

First web-based product released: bSelling

Last week we -- Austhink Software -- released our first web-based product, bSelling Opportunity Management, an add-on application to the web-based Salesforce CRM.

Yay team!

Here are some brief notes about the product (a visual tool to enhance the performance of sales teams), its placement (as an add-on to Salesforce CRM available through salesforce.com's AppExchange), and the development experience (using Adobe Flex + Django talking to Salesforce).

The Product
The best way to get a taste for this add-on, which helps the salesperson to better Qualify (i.e. estimate the percentage chance of closing the deal) , better understand the customer's pain(s), and ultimately pitch more effectively to the customer's needs -- is to check out the 2 minute (approx.) introductory video:

bSelling video

For non-sales people, here's my distillation of Solution Selling, one of a family of consultative approaches to sales -- along with SPIN, Strategic and Consultative Selling -- that bSelling is intended to support.

The Placement
Austhink's Softwares previous products, bCisive and Rationale were PC-based and intended to create new markets: Rationale for improving Critical Thinking in education, and bCisive for applying Visual Thinking to business.

For our first web-offering we decided to pick a more targeted application -- consultative selling -- and apply our visual approach more narrowly. This enabled us to go from "let's port bCisive to the web" (a daunting undertaking on account of the size of the pre-existing product) to "let's port the bits of bCisive that will help with consultative selling" (a smaller and more customer-centric) undertaking.

We aimed from the outset to put the resulting application on Salesforce.com's AppExchange, as a way to make bSelling visible to our chosen market segment, and to offer easy integration with the leading web-based CRM.

Development Experience
We accomplished this with a team of 3 in just over two months, admittedly making use of some initial work on a web-port from last year, plus our accumulated experience from bCisive, Rationale and some earlier non-commercial web-based projects, most notably Aaron's side-project, Path of a Hero.

We found that Adobe Flex / AS3 gave us the graphic power (and portability across browsers) that we wanted for the front-end, with our architecture hanging off a slightly souped-up version of the PureMVC framework. We use Django / Python / MySQL for the back-end and use AMF3 / PyAMF to get fast communication between the back and front-ends.

The big unknown for us was integration with Salesforce CRM. It turns out that their APIs and docs are pretty good, and we were able to embed our app as a web-page in their S-Control.

Now, it is possible to build apps entirely on their force.com platform, but we chose not to because:

• It required a steeper learning curve
• We had a pre-existing technology investment
• It would couple us completely to their platform

On the negative side this meant that we had to subject ourselves to a nerve-wracking security review. This involved submitting our organization's written policies plus go under attack from their review team. It was certainly "an experience", a bit liking going back to University for another exam, but their liaison was helpful in guiding us through the process, and we achieved a provisional pass first time (much relief).

One note for start-ups: There is normally a $US5000 application fee for the review (annual!). The two ways to waive this are to develop directly on the force.com platform (i.e. inside the Salesforce sandbox), or to supply a free version of your app. We went with the free version.

Compared to the security review, the final review was less demanding.

The Future
We are putting the finishing touches on an "export to PowerPoint" feature for the paid version, so that a salesperson can grab some snappy visual slides to supplement customer presentations.

Naturally getting the word out is paramount -- thanks to AppExchange we've already had some people checking out the video and installing bSelling-- and we look forward to responding to customer feedback with further refinements. To this end we have set-up UserVoice to help out with this. The AppExchange infrastructure requires people to leave details, so we will also follow up (selectively and politely) with some of the early adopters to find out worked and what didn't.

Beyond bSelling on Salesforce we are also look at integrating it with other online platforms (SugarCRM is an obvious candidate).

And beyond that lie other applications in Sales and other business verticals. We aim to apply our skills and technology to create other "Enterprise 2.0" apps, but in these -- ahem -- challenging times we need to be strategic about picking off targets.

Hooray for Captain Balding! And Captain Underpants!

Having recently started school, my son Jake reports that he spends many a happy recess playing super-heroes with his friend, Max:

Which super-heroes do you play?

"I am always Captain Balding and Max is always Captain Underpants.", says Jake.

Intriguing.  What is Captain Balding's super-power?

"We have different powers every time, but one power we always have is super-phones."

It all sounds marvelously imaginative, and they are fixated on these characters.  But where do they come from?  My best guess is that the Captain Balding character originated as a kind of a cross between me -- bald and apt to make my children address me as "Captain Daddy" -- and Groucho Marx's Captain Spaulding in Animal Crackers:

Song: Hooray for Captain Spaulding (not Balding)

Now, as for Captain Balding's great partner in crime-fighting, Captain Underpants, a little research reveals that he is a legit. super-hero after all:

Captain Underpants rap

With these two heroes to protect us, we simple townsfolk can again sleep safe at night ... 

... I think.

This Prager is a bigger nerd than me

We share the same initials and the same surname, but David Prager is (clearly) a bigger nerd:

When a stranger broke into Silicon Valley executive David Prager's house yesterday, he did not call police or reach for a gun - he logged on to Twitter and set up a live video stream.

Read on ...

So there you go: Another D. Prager -- other than Dennis -- in the news.

Three things that my children have learned

Just for fun I asked my son, who has just started school, what three things he has learned at school.  Jake's (very definite) response:

1. Respect,
2. Sport, "and finally:"
3. Italian.

I then asked a similar question of my daughter, who has recently commenced kindergarten.  Ella's reply:

1. How to draw,
2. That [another child] is not my friend, and
3. That I do not know how to draw.

HtDP for the experienced programmer

I am a fan of Scheme (a programming language for the soul) and SICP "the greatest book on programming ever written", but my hat goes off to the creators of DrScheme, a great interactive environment for the beginner and experienced programmer alike.

The other night I swallowed my pride and started to work through HtDP (How to Design Programs), the PLT Scheme gang's reaction to the fact that SICP (which came from MIT) while great for the suitably talented individual does not by-and-large work for the mainstream. In this book they explicitly teach program design, a systematic approach to thinking and problem-solving that it seems only a few people get by the more traditional osmotic process.

HtDP is covers a great range. Although principally geared to college level, it can be taught in high schools (at a slower pace), and can teach most experienced practitioners more than a thing or two.

Additionally, the people on the PLT Scheme mailing list are incredibly friendly and supportive. Here's what Matthias Felleisen, first author of HtDP (among many other things) wrote when I mentioned that I was starting to work through HtDP, but was having difficulty restraining myself from skipping ahead:

If you are an experienced programmer, you should read HtDP like this:

• Read the sections whose title starts with "Designing ...."
• Also read the "iterative refinement" sections
• Pick five exercises in the preceding and/or follow-up section and solve them according to the recipe
  [my emphasis]
• Unless you're stuck move forward
• Try to understand the "symmetry" between data definitions and templates

I expect that somewhere around late part II, you will slow down. You may pick up real reading as of part III, though some may make it thru III and only "stutter" in IV.

Also:

• Use check-expect to express your examples/tests
• Avoid draw.ss exercises, replace them with world.ss but that's a non-trivial switch

And holler if you are having trouble -- Matthias

In short: Great tools, great teaching materials, supportive and experienced community.

Software Product Design and the Collaboration Process

In the last few months my team and I at Austhink software have had a wonderful graphic designer -- David Urbinder -- consult on our products. Much more than design icons and images, collaborating with David has led to improvements in overall visual design, and more deeply into dynamic behavior (interaction design) and consequently the overall usability and appeal of our products.

Working with someone from a complementary design background helps to trigger creative sparks. David has pointed me to this article by Nate Fortin about the non-separability of design into different disciplines in Cooper Journal. Cooper Journal is hosted by Cooper Design, whose principal Alan "Father of Visual Basic" Cooper wrote the influential book About Face, and the provocative and important The Inmates are Running the Asylum, both of which I also highly recommend.

One of the issues that we are grappling with is how best to engage expert outside design consultants like David. At the moment we are doing a blend of some consulting time, plus directed tasks, spread out over time. The benefit of the spreading out is that we get the benefit of David's creative input early, when it can have a formative effect, and guidance at later stages too as the product becomes more "locked down". Coordinating our schedules is a "fun" part of this approach, and is of course more challenging than just employing him for confined blocks.

Finally, if you want to commission David, I would love to link to his web-site, but I believe that it is not ready for public consumption just yet (hint, hint ;-). In the meantime, David can be contacted on email at urbinder@gmail.com.

New tag line?

The problem (from my last post): Get our draft mission statement:

We use our skills in software, game design and visual animation to make our customers' business applications more fun (and much more effective).

down to a snappy under-five-words tag-line.

Here is an unfiltered list that I came up with while sitting through a talk on "cloud computing":

• Make work fun
• Make work visual and fun
• Make work fun and visual
• Work as a game
• Game the system
• Games that work
• Turn on your brain
• Work meets play
• Smart play
• Intelligent play
• Play smart; work smarter
• bFun. bSmart.

More ideas?

Mullenweg's 12 rules for getting from 1 to 100,000 users

Matt "Wordpress, Akismet, Ping-o-matic" Mullenweg has 12 rules for getting to a large number of users:

1. You have to be the most passionate person involved.
2. Get off the computer - the act of writing things down on paper frees the mind, allows for the juices to really flow.
3. Obsess about the details, down to the space between two letters.
4. Do your own support. You have to be able to feel the pain of your users. Document everything. Make it as easy as possible for your users to contact you.
5. Blog every step of the way. Keep all of your users in the loop at all times - they will love you. Communicate with them and put them in the driver's seat.
6. Have a great tagline. If you can't describe what you are doing in less than 5 words, edit it, shave it down.
7. Frame everything you're talking about in a context for your users. What are you going to do for them?
8. Get out of version 1.0 as fast as possible. Most people make their successes on something different from where they started. Be flexible. User feedback is the most valuable asset. Don't let yourself be too led by your first users. Listen to the silent majority. Keep the majority in mind.
9. Track yourself.
10. Know what to do if you are successful.
11. Start strong, end strong. People don't often remember what was in the middle.
12. Be a pain killer, not a vitamin.

The 46-minute podcast of Matt's talk.

Excellent food for thought. One that caught my eye was #6. The problem: Get the shiny draft mission statement down to a snappy under-five-words tag-line.

Victorian bushfires: A personal appeal

Unprecedented bushfires have affected my home state of Victoria, Australia, since last Saturday. I live in the capital city, Melbourne which has been largely unaffected, but like almost everyone else I have friends and family who have had narrow escapes.

Unfortunately, many have not been so lucky. Over one-hundred-and-eighty people are confirmed dead with estimates that this will rise to over 300.

Today I was saddened and shaken by the news that a family that I know -- a mum, a dad and two children (only a few years older then my own) -- perished while defending their home.

What to do?
Like most Victorians we are donating money, in our case through the Red Cross Bushfire Appeal. In addition Andi is donating patchwork quilts to the destitute. We are looking into other ways that we can help.

I urge all Australians -- especially Victorians -- to donate generously, and if possible to also help by donating goods, personally volunteering, and offering shelter to those rendered homeless.

My son the vigilante

In the round-up to Jake's first week at school, when asked about his day, Jake said in passing:

"I had to wrestle one boy, to stop him from being mean to another child."

Further questioning failed to yield meaningful elaboration. In the absence of calls from the school I guess we'll just have to assume (hope?) that Jake was on the side of the angels.

Shall we learn, or wrassle?

So to any bullies reading this, remember: "Don't mess with red".

Great interview question

This article suggests that you should always ask

"What do you do in your spare time?"

since it tells you a lot about what the candidate is passionate about.

Now, I have been asking this sort of question in social settings because I am not a great smalltalker -- although I'd like to learn one day ;-) -- and usually asking that question (or what's your passion or hobby) get's people engaged and open up. Unfortunately some people are very obsessional and will launch into long monologues at the sniff of such an invitation, in which case it's time for me to interrupt, excuse myself and go and get another drink (especially in this heat).

Anyway, while I think it's an interesting question, I am not sure that it is that easy to interpret the answers. I would suggest supplementing it with a follow-up when there is no obvious connection:

"What have you learned from full contact macrame [or whatever] that relates to your day-job?"

Let the interviewee do the hard work!

Truth in Parody

If you can't decide whether something is a conspiracy or a stuff-up, assume a stuff-up.

But often the conspiracy theory is much funnier, and just rings truer. Witness this spoof interview with Bjarne Stroustrup, creator of the C++ programming language. Snippet :

Bjarne: Well, one day, when I was sitting in my office, I thought of this little scheme, which would redress the balance a little. I thought 'I wonder what would happen, if there were a language so complicated, so difficult to learn, that nobody would ever be able to swamp the market with programmers?

Gold.

Distillation of Solution Selling

A few months ago we did a training course on Solution Selling, and yesterday I bought the book. After reading the introduction -- a bit more to go! -- thought that it would be a useful exercise to try to describe its essence in my own words:

Origins
Solutions Selling is a codification of smart sales practices by Mike Bosworth dating back to 1983. Originally Bosworth went straight from College to pursue a career in the technical support at Xerox corp., before it was suggested that he try his hand at sales, which he did (at first reluctantly). The book was published in 1995.

A Consultative Approach
Rather than foist your product on an unwilling (or even willing) prospect the Solutions Selling approach encourages you take the buyer's perspective and work with him or her in a non-pitchy way. By the end of the process a decision to buy should be a "no-brainer":

• the customer should feel ownership of the resulting solution
  
• the value should be evident to the customer how the purchase leads to enhanced capabilities
• these enhancements should be quantifiable, so that the purchase price is justified to other people in the customer's organization
  
• the customer should feel personally empowered by the experience and the result
  
• the personal relationship with the salesperson should be perceived as positive

Applicability
Solution selling lends itself particularly well to large complex offerings. For example

• Service and product combination
• When you compete on customization and/or integration
  

However, the principles can be applied on smaller scales as well, exercising judgment about how much and which parts of the process to apply.

Theory
Let's divide prospective customers into groups / stages:

1. Not in target market: No need for your offering(s).
2. Latent need: Not aware of a need that could be satisfied by purchase
3. In pain: Aware of the need ("in pain"), but unaware of how your offering can help
4. Vision creation: The prospect has a vision or a "Solution", ideally including your offering

The key is to be aware of where the prospect is between steps two-to-four, and not get out-of-synch. with the prospect. Classic example: There's no point trying to tell someone that they need your product if they don't perceive it that way.

Examples:

1. If the prospect is in group 1, go after someone else rather than try to sell them something they simply don't need. Better to steer them in the right direction and build trust and respect for the longer term.
2. If the prospect is in group two, use appropriate questioning to get more clarity, but also to move the prospect toward a clear perception that they have a real need (which would move them into group 3)
3. Quantify the pain, find out who else in the client organization is affected (and go talk to them), find out who has the power to buy, find out which hypothetical capabilities would enable them to address their pain
   
4. Two possibilities: They are already heavily leaning towards a competing vendor's vision / offering (you need to realize this, and use FUD to un-sell them and get them to come over to your vision -- "re-engineering"), or use what was learned previously to put forward a jointly-developed vision that they know will give them real, quantifiable value.

Application
The actual Solutions Selling methodology explicitly fleshes out how to do it!

It includes lots of advice and tools including a detailed and distinctive nine-block vision processing model.

Challenges in putting it into practice
Naturally, Solutions Selling is not a panacea (silver-bullet):

In a freely available McKinsey & Co. report (registration required), Solutions Selling: Is the pain worth the gain?, the following points are made:

Unfortunately, our discussions with over 60 solutions sellers suggest that three out of four companies selling solutions fail to see sustainable economic impact.

They suggest that some possible keys to getting Solutions Selling to work well (my emphasis):

First, you have to understand how a solution is positioned in terms of two key variables, customization and integration. This positioning drives the basis of your competitive advantage and - most crucially -the "pain/gain" trade-offs you need to understand.

Then, you have to execute quite differently from a standard product-based go-to-market model in at least the first two - and preferably all - of five key dimensions:

1. Create distinctive solutions value propositions using customer business metrics, not product price/performance metrics.
2. Radically change the selling approach, and if necessary, the sales talent.
   
3. Price solutions based on total business value delivered, not component features.
4. Align the entire organization, not just sales, with the solutions opportunity.
5. Maintain control of all aspects of implementation to ensure end-to-end value delivery.

Solutions selling is not for everyone. But for those who understand and can implement these imperatives, there is tremendous upside.

Comment: The essential dimensions, one and two, on my reading amount simply to properly applying certain parts of Solutions Selling properly (as distinct, I suppose, from paying lip-service).

However, this may not always be simple. The report suggests that on average 2/3 of salespeople with a background in product-centered sales are unable to successfully make the shift to Solutions Selling. They recommend that "stars" be recruited from other areas, suggesting that star-sellers are either:

• Already doing things similar to Solutions Selling (so the shift is smaller),
  
• Are more adaptable than regular salespeople in terms of trying a different approach, or
  
• Will be successful independent of the methodological approach adopted by the sales-team!
  

Conclusion
Solutions Selling is a consultative sales methodology that reminds me a bit of the Getting to Yes school of negotiation in that it aims to move away from negative relations between the two parties (e.g. adversarial, distrust, fear) towards cooperative problem-solving to seek out win-wins.

It has repercussions for the individual salesperson in that it encourages a specific systematic approach, but promises improvements in:

• efficiently deciding which opportunities to pursue
• improved client engagement
• better professional relationships and reputation

leading to conversion-rate, sales figures and referrals. For the organizations that successfully embrace it, better sales performance is anticipated, but the following are needed:

• Suitable organizational alignment with suitable offerings and pricing
  
• Sales and other staff to execute on the approach (or at least most of it)

Granted organizational alignment, it stands to reason that certain organizational initiatives can increase the likelihood of individual and company-wide success when adopting Solutions Selling (and similar approaches):

1. Training
2. Mentoring
3. Recruiting
4. Technological support (tools that make the tasks easier, help apply essential parts of the methodology appropriately)
   

Inspiration

Bob Franklin, who programmed up the first electronic spreadsheet, VisiCalc, in 1978 working with Dan Bricklin -- whose idea it was -- has been writing up the history. I found the following inspirational and salutory. How to build a software product:

Design Principles

VisiCalc was a product, not a program. Decisions were made with the product in mind and, to the extent possible the programming was towards this end. In practice it was more complicated as we were designing against the limitations of the personal computers, price point and, most important, what the user could understand.

The goal was to give the user a conceptual model which was unsurprising -- it was called the principle of least surprise. We were illusionists synthesizing an experience. Our model was the spreadsheet -- a simple paper grid that would be laid out on a table. The paper grid provided an organizing metaphor for a working with series of numbers. While the spreadsheet is organized we also had the back-of-envelope model which treated any surface as a scratch pad for working out ideas. Since we were used to working with powerful computers without worry about the clock running, we already had the experience of focusing on the users needs rather than the computers needs.

The ability for Dan and I to work as a team was crucial. While he could've written the program, the fact that he wasn't gave him the freedom to focus on what the program should do rather than how to do it. I could appreciate his reasons and would eventually accept that I had to change code that I had labored over. We were able to find ways to take advantage of the limited space available for the program in deciding what features to include or not include.

The original version put the entry area at the bottom of the screen. By playing with this simple prototype Dan found that it was better to put the entry area at the top of the screen and I made the change to the evolving program.

In addition to prototyping, Dan put together a reference card for users. If we couldn't figure out how to explain a feature on the reference card we would change the program. The original method for copying formulas was too complicated so we just changed the design rather than try to explain it.

The more things change, the more they stay the same.

Understanding the Financial Crisis

Here's a readable explanation of the Financial Crisis as explained by a former president of the MIT Black-jack team, in terms of martingale strategies, reward systems, and self-deception.

Kids Rule

Over the holidays we gave Ella her own room (formerly the "play room"), and redecorated both her and Jake's rooms in the process.  They didn't really want to be separated, but were appeased when it was pointed out that they could visit each other for sleep-overs.

I felt that they should be able to set the rules in their respective rooms:

Jake's Rules for his Room

1. Don't take away a train when someone's playing with it.
2. Don't rip the Thomas and Mr Men and Little Miss books.
3. Don't break up the track.
4. Don't interrupt a story.
5. Be gentle with the lego.
6. Don't rust the trains, and don't scratch people.
7. Don't jump on the bed.
8. Be careful when you wind up the sling bridge; it might break.
9. Don't come in when I have privacy.
10. I like tickling, and stop when I want you to stop.

Ella's Rules for her Room

1. Don't jump on the bed, pillow and doona.
2. Don't interrupt my books and don't break my boxes.
3. I like tickling, but stop when I have had enough.

Andi and I are still working on our rules for the rest of the house, but here's a preliminary list:

1. Mummy and Daddy are the bosses of the house.
2. No biting, slapping, or hitting.
3. When you finish your food, bring your plate to the kitchen bench.
4. Use an inside voice.
5. No TV on school mornings.
6. Children must brush teeth and get into pyjamas before getting "bedtime choices".
7. All family members must support the Collingwood Football club, or leave home.
8. You get what you get, and you don't get upset.
9. Remember to put out the bins on Thursday nights.
10. Full participation is expected during Shabbat blessings, and this includes guests.
11. Don't waste water; the farmers need it.
12. A quick game's a good game.
13. The house must be tidy before the cleaner comes to clean.
14. Obsessions, such as martial arts, patchwork quilting, trains and fairies are to be tolerated, nay, respected.
15. Tickle the mickle is the preferred format for tickling.

Read my other blog like a book

I recently added a table of contents page to my other blog, Martial Arts and Modern Life, with section headings available from every page of the blog. It should make that blog much easier to read for the someone coming to it for the first time:


The table-of-contents post appears on the left, with chapter headings and links, but the neat "feature" is the table-of-contents that appears on the top-right of my blog, making it easy for me to navigate, and for readers to get an overview and dive in to whatever interests them.

Already I have had some positive feedback about this feature, and I would encourage others to emulate it for the sake of their readers. It seems to make a nice complement to tags, which are a bit more like an index, and archives, which tell you what's new.

The set-up steps in Blogger (it should be similar for other platforms) are:

1. Invent chapter headings for your blog
2. Create the table-of-contents blog entry: E.g. myblog.blogspot.com/toc.html, or (nowadays) a page and include your chapter headings.
   
3. Tag every heading with using Edit HTML in the blogger editor by wrapping it in anchor tags: e.g.

   <a name='chapter1'>Chapter1</a>

4. Go through all your old posts and put links to the better ones under the appropriate chapters.
   
5. Make a text widget that points to your table-of-contents entry and the chapter headings. The hyperlinks from the chapter-headings take the form

   <a href="http://www.blogger.com/myblog.com/toc.html#chapter1">Chapter1</a<

6. Place the text widget somewhere prominent.

Maintenance is even easier:

• Each time you add a new post that fits your theme, add a link in your table-of-contents post.
• Occasionally you may want to add a new "chapter", which involves editing the widget as well, but this should be a fairly rare event once you have your categories straight.
  

Now I just need to apply the same technique to this blog!