Better Writers Than I pt 2

Unsurprisingly, people with more brains and experience are sometimes capable of discussing this business better than I can.  Max Schireson from 10gen does a good job of explaining pricing in his recent blog post here: http://maxschireson.com/2012/05/14/the-value-based-pricing-trap/.

The vendor viewpoint is slightly more comprehensible, it seems.

Full disclosure: I met Max once, when I was interviewing at 10gen.  Impressive guy.

The Mission Matters

(TK: Zappos vs. Amazon.com, two absurdly customer-centric companies that take divergent approaches to service)

I've actually been struggling with this post for over a month.  I've decided to narrow my focus just to customer support in order to get it out.

Also, I want to use my own voice more from now on.  It's really hard to write about this kind of stuff with a straight face, and I'm not actually so dry in person.

A company must have phenomenal customer support as part of their mission from an early stage.  It's nearly impossible to establish a good support organization down the line because the value of support is difficult to measure, and big companies necessarily become driven by metrics.

And what constitutes phenomenal support?  There's a fairly middlebrow observation that the primary impact of support is not solving problems, but giving the customer a good experience.  I've worked with some folks on my teams who couldn't solve problems, but were excellent at dealing with customers.  I'd prefer to work with a guy like that over a highly effective but less empathetic individual.

And what is a good experience?  An interaction that results with the customer having a good opinion of your products and your people, and feeling confident that the issue is being addressed.

In my opinion, you need to hit a few key points:

• Good interactions
• Self-explanatory, but this has to emphasized at the most core level.  It needs to be part of your identity.  If not, folks on the team will slip occasionally.
• That it's easy to say "treat customers well" is the point.  Everyone talks about it; you have to live it.
• Accessibility
• Some folks prefer phone, some prefer email, some prefer a web portal
• Don't corral your customers into a single way of interacting with support.  It's potentially a lot easier for your team to be flexible than to force your methodology onto all of your customers.
• Match your hours to your customers'
• Visibility
• Provide some kind of evidence that their issue matters, such as a case number, or description of the escalation path that you are taking
• Not every problem is solved during the first touch point.  Just as you need an internal system to collaborate on customer issues, your customers need visibility into your overall process and into the status of their particular interactions with you.

Guess what?  All easier said than done.  That's why the mission matters.  If treating your customers well is not part of who you are, it's way too easy to cut back on service, reject issues, and under-invest in support systems and staff.

So, before your company gets too large, put tools, processes, and people in place to provide phenomenal support.  Make it part of your mission, make it part of your identity.  Take whatever mission statement you have now, and append "provide ridiculously good customer service" to it.  If you don't get it right from the start, you are gonna have a big struggle getting it right later.

Better writers than I

Alexis Madrigal has said it better than I ever could:
http://www.theatlantic.com/technology/archive/2012/04/the-jig-is-up-time-to-get-past-facebook-and-invent-a-new-future/256046/

Maybe another point to take away is that we're much less creative than we're all given credit for.  With enough people, you always get some amount of innovation, but most folks--even the intelligent ones we depend on to be leaders--will follow an established path.  The last half-generation of great minds all went into finance, to iterate endlessly on the same flimsy premise (eliminate risk through math! get rich and live forever!), much like the way everyone  is beating on social/local/mobile today.

Young people aren't piling into startups because they're all thrill seekers.  It's actually much less risky than the prevailing, pre-Internet perception would have you believe.  Ad-supported products aren't in a zero-sum competition for users.  This makes it easier for a company to post good stats and raise money, and consequently less risky to work there.  Because these firms and their employees can do reasonably well without taking big risks, they don't innovate.

Unconventional Transparency

I think everyone inside of an organization should be able to read everyone else's expense reports.  Give that idea a minute to sink in.  Is there really any downside?  Imagine how useful it would be to look at where your coworkers have stayed in Chicago, or the average cost of a one-week trip to Toronto, or countless other patterns that are too specific to be outlined in your policies.

Assume management and accounting still take responsibility for what actually gets paid out, so it's not like the judgment of others will prevent you from getting your expenses handled.  Do you think your colleagues would try to shame each other into spending less?  Or goad each other into spending more?  Does it matter?  The whole conceit is that your management should have a handle on this.

And as such, the only people with anything to lose in making expenses public are your management.  It would expose the degree to which there is iniquity in the system.

There seems to be a convention by which anything to do with money is not public knowledge within an organization.  Compensation is an obvious example.  My current employer actually guards sales figures  (in their defense, they are protecting mainly unaudited, nonpublic information) and contracts from folks who don't have a vested interest in the accounts in question.  What about the costs of office space and equipment?  Or HR data like vacation planning?  Or timesheets for a services team?

99% of the time, none of this information is needed for me to do my job.  However, I think great things can be accomplished when you open up your data--internally, at least.  Some companies even share all their compensation data.  Rather than foster jealousy and rancor, transparency can be used to validate that a company is being fair or at least consistent with regard to its treatment of employees.  It sounds trivial to say this, but even if they don't own stock, employees are stakeholders in a business and deserve to understand important HR and financial figures.

I like information.  A lot.  And I get the question "why do you need to know that?" way more often than I should.  Rather than keep employees in the dark, I think the right question is, "why shouldn't we share this?"

Endless Optimization, Consumer Apps, and Complexity

I had an interesting conversation with my flatmate over brunch yesterday.  He currently works at a well-funded B2C startup.  While his company is working on many interesting problems, they also have to dedicate a lot of resources to optimizing ad displays in order to keep up revenue.  It's kind of ironic that some of the best minds of our generation are at least partly dedicated to ads.  The brainpower that is focused on display ads (including, occasionally, my flatmate), is just staggering.

Well, not ads in the Mad Men sense, but really more in the sense of modeling and optimizing for human behavior.  Where do we look on a screen?  What makes us click on an ad?  How many people will tolerate a modal ad/front door, how many people will be driven away? Entire businesses exist just to drive marginal improvement in advertising ROI.  These improvements are driven by better data on users and better execution on ad networks.

This is starting to sound familiar to me.  Ad sales is being treated like an inefficient market, where actors and prices can be exploited for profit.  It doesn't stop there. Consumer apps, like Groupon and its clones, or Mint, or Foursquare (vis-a-vis their partnership with American Express), are providing a service in exchange for data on you. Target is modeling you and your lifestyle via your purchasing decisions.  Everything you do feeds disparate systems that, in effect, predict your behavior.  Specifically, they try to predict your purchasing decisions.  In turn, this increases the value of ads or promotions that are shown to you, because those ads are thought to be more relevant.

Why does this make me think of the rise of quantitative finance?  Because it looks like an increasingly complex system involving more and more algorithms, autonomous actors, and dependencies.  The array of systems keeping tabs on your wallet and personal life might reside in different applications, but that doesn't mean they are not interrelated.  The algorithms designed around your prior behavior might be able to learn, but that doesn't mean that they can't be gamed.  To me, this sounds increasingly like the advent of the various financial bogeymen of the past two decades. Millisecond execution on ad networks could be like HFT. Behavioral modeling, data leaks, anonymous players in what is supposed to be a transparent system--it's all there.

Problem is, we know what happens when finance goes bad.  Fraud, market crashes, firms destroyed, savings wiped out.  We've seen it.  But what happens when optimization and consumer apps run amok?  What happens when the advertising ecosystem, the revenue model upon which many apps and services depend, begins to creak under its own complexity?

Maybe we'll see a collapse in the ads market, as fraud and data leaks destroy the value of personalization.  Maybe consumers will become disenchanted with ad-supported services because ads will become increasingly intrusive and creepily specific.  Maybe incidence of identity theft will skyrocket.  Maybe bank accounts will get hacked.

I'm not saying these things are guaranteed.  Finance, and stock markets in particular, lends itself to certain types of abuse and risk-taking.  Web and mobile apps that sell ads to survive are a little less foolhardy, at least when it comes to their main source of revenue.  But I do see risks to the kind of endless optimization and gaming that is endemic to the modern web, and I think consumers and developers need to take into account that a disjoint system of behavior-tracking applications could have unintended consequences.

Pricing Part III: Cost Benefit Analysis

So, we've talked about models, we've talked about price targets from the vendor perspective, let's get into the buyer's point of view.

Software has a supposed value.  Your business accomplishes X today through some combination of labor, fixed costs, and recurring costs.  Take a reporting system, for example.  Maybe you just use Excel, some databases, and some degree of home-brewed automation.  So, your fixed costs cover software and hardware, recurring costs for maintenance, and then labor for the amount of manual effort required to design and deliver the product.

A solution to replace your system should effectively pay for itself by reducing long term costs and/or saving effort.  Pretty obvious, right?  But how can you be sure?  The system you built in house might have low one-off costs, albeit offset by higher labor demands.  You could quite possibly spend the same money on a new system or on adding more human resources.  Adding people, while not easy, is on some levels much less risky than taking on a new system.

You could bring in consultants to try and assess deeply that value of buying another system, but this too is fraught.  Consultants like change.  Change and uncertainty is what keeps consultants in business.  The consultant might even think that his or her company will get a piece of the action when it comes time to deploy the new system.  Similarly, an in-house assessment is tricky because of vested interests in the current solution.  Your purchase of a new system potentially means eliminating jobs, just like putting a more advanced machine into an assembly line.

All you want is the cost-benefit analysis.  The decision to buy a software solution just needs to add to the bottom line over a reasonable amount of time, without distracting your resources from higher-value activity.  But you can barely trust anybody to give you a straight answer on cost-benefit.

To get to the root of the matter, you can attempt some thought exercises.  Would you buy at a million dollars? 10 million dollars?  Would you take it for free, just knowing that there will be effort to implement the new system?  Try plotting a function of the cumulative costs of your options and, if they intersect, see how many years it might take for your purchase to add value.

For example, your current solution can be modeled as a function of time.  For year X, it's something like:

f(X) = (1 + X) * ((human labor + annualized hardware costs) * uncertainty)

Human labor is, of course, the cost of the people to build and maintain the solution.  For something built in house, it's likely to be quite high.  You might have several fairly expensive developers plus maybe an offshore QA or integration consultant.  You will need more hardware over time, but you can cap ex that.  Uncertainty is a coefficient that recognizes the non-scalability of your solution: developers leaving, new requirements that are not in scope, and so on.  You can experiement with different values, but try something like 1.2, as +20% is kind of a standard fudge factor.

What about buying?  There area few more inputs.  Something like this:

f(X) = software + hardware + implementation + (1 + X)*(maintenance + human labor)

Ideally, there is no uncertainty coefficient because your vendor is competent and the solution is a good fit.  Your human labor expenditure should be substantially lower.  So, this function crosses the y axis at a much higher point, but has a lower slope (in theory).  The question is, how many years does it take for this function to save you money?

That's something I'd like to know more about.  Is there an accepted number of years within which a business decision needs to add value?  This could apply to many kinds of major expenditures--equipment, office space, marketing, etc.  Cap ex rules inform on this somewhat, but I'm inclined to think that there are less codified rules out there that experienced executives use to make this type of decision.

Getting to No

Business writers like to talk about reaching consensus and influencing other people.  This is often in the context of closing a deal, or requesting a raise, or otherwise "getting to yes".

Let's talk about getting to no: the art of disabusing people of bad ideas.

It's actually a fairly common interview question for client-facing jobs: tell me about a time when you had to convince somebody that he/she was wrong.  This question assesses how you handle conflict, your ability to navigate workplace politics, and your ability to empathize enough with somebody else to understand just why they're clinging on to bad idea.

By the way, let's assume that the bad ideas we're talking about here have at least a trace of legitimacy, unlike my repeated requests to turn one of our empty offices into a ball pit.

Some thoughts:

• Be respectful.
• Unless you really don't want anybody to like you, you can't just say "no"
• Work isn't always about being liked, but when you've got a relationship with your colleagues or customers, it helps to treat their point of view with respect and to try and reason through things.  Maybe they're right and you're wrong.
• If you injure somebody's pride, that person may react by holding on to a bad idea even more strongly.  You know the trope about a grumpy sys admin holding up a new IT project?  This happens when ops team members aren't taken seriously enough because they aren't on the business side.  Respect gets things done.
• Empathize.
• Build support for your lack of support.  Talk to stakeholders individually.  Be a politician.  Figure out what's driving this decision and what everyone's interests are.
• Put yourself in their shoes, can you see their point of view?
• Make a case.
• Gather real evidence, don't just shoot something down because it feels wrong.  Speak to the interests of the stakeholders.
• Communicate your concerns in person or on the phone, and in chunks that are easy to digest.  Nobody is going to want to read a long email explaining why he or she is wrong.  We have a capacity for ignoring information that makes us feel bad.
• When you discuss the risks of a bad idea, do so with impartiality.  Rather than attacking the validity of a feature that might slow down system performance, talk about the importance of the user experience (i.e. speed and reliability).  Talking points like this are powerful rhetorical tools because, basically, nobody can disagree with you ("No!  This flashy feature is more important than whether or not the system runs!").

Let's take what is probably a common example: 

You've got a salesperson who might have misstated some technical information about your product.  The customer IT has some very strong opinions about this, and while the business users don't really care, they tend to trust their IT team.  Your developers won't get within a mile of this deal and your delivery team is going to face the fallout from having mis-sold the product.

You're now staring down a very painful project, what do you do?

First, don't embarrass your sales guy.  Really.  It won't get you any closer to solving the problem.  The only person who can credibly contradict your sales rep is your sales rep.  Chances are, the sales guy isn't particularly wedded to his misstatement of your product's capabilities.  Make him comfortable with going back to the customer and clearing up the misunderstanding.

Ask yourself why the customer is hanging on to this idea.  Maybe it means less work for them, maybe they told the CTO about it and she's excited, maybe they think it will get them a bigger bonus because the solution is so spectacularly perfect.  Consider that the customer might have legitimate technical, personal, and professional reasons for supporting this misconception.

When you try to take this idea off the table, think about how to address these lowered expectations: there are positive tradeoffs on the tech side, your salesguy can talk to the execs, following your own best practices & staying within the capabilities of your software will make this a raging, bonus-inflating success.

Ultimately, you're just getting everyone's best interests aligned, right?  We all want this thing to work, don't we?

By the time you're ready to publicly debate this idea, you should already have convinced some stakeholders to take your side.  You should already have a solid case for saying no.  All you're really doing is showing the last hold-outs that they're on the wrong side of history.  If you've laid your groundwork well, the customer might even reject the idea without further prompting from you, and the project will chug along without any hint of prior discord.