Thursday, October 27, 2011

Skimming : Don't Just Roll the Dice

Don't Just Roll The Dice - A usefully short guide to software pricing

Some – but not too much – economics

  • From the diagram, you can see you should price the Time Tracker 3000 at around $300. It’s not where you’ll sell the most units, but it’s where you’ll make the most money. (p.13)

Pricing Psychology: What is your product worth?

  • These two facts, the awfulness of the product and the magnitude of its success, can be reconciled if you understand that Sage’s product is more than just the software.(p.16)
  • If you want to change how much Willhelm will pay for your product, then changing the product is one option, but only if you can also change his perception too. In fact, it turns out that you can change Willhelm’s perception of your product’s worth without touching the product at all. That’s one of the things marketing is for. (p.18)
  • People base their perceived values on reference points. If you’re selling a to-do list application, then people will look around and find another to-do list application. If they search the internet and discover that your competitors sell to-do list applications at $100 then this will set their perception of the right price for all to-do list applications. (p.19)
  • Ultimately, it comes down to differentiating your product. (p.24)
  • If your customers can’t find a reference point for your product, then they look for proxies, or signposts. (p.25)

Pricing Pitfalls

  • If you are going to compete on price, then you should minimize the possibility of a counter-reaction from your competitors. (p.27)
  • They put a copy of your software into the hands of people who will not pay, cannot pay, are too dishonest or too principled to pay, or who simply don’t value your work that much. However, a pirated copy will end up, eventually, in the hand of somebody who will pay.(p.29)
  • The second reason that pirates can be your friends is that they are a bellwether. They indicate the existence of a market failure. (p.29)
  • There are some things you can do to mitigate switching costs, and even to use them in your favor.... Early versions of Microsoft Word not only opened WordPerfect files, but had a dedicated section in the help for WordPerfect users, and even allowed you to use the WordPerfect shortcut keys. (p.31)
  • You might have spent one hundred dollars developing your product, or a million, but that money is all spent. Gone. It’s a sunk cost. What matters now is not how much you’ve spent, but what people are prepared to pay. (p.34)

Advanced Pricing

  • That’s what’s versioning is about. It’s a mechanism of segmenting your users according to their willingness to pay. You figure out if you can group your customers in different ways, and then see if those groups are willing to pay different prices for your product. (p.36)
  • But here’s the second subtlety. This only works if people can easily compare the products being versioned. (p.39)
  • If you insist on selling a site license then make sure you define ‘site’ well. Is it for a specific office, or country, or worldwide? (p.45)
  • You must consider your customers’ purchasing processes when you set your prices. If you’re selling to businesses, then there will be a number of thresholds that you need to think twice about before crossing. ... At each stage, not only does the cost increase, but the hassle does too. If you can figure out where these thresholds lie (and they move around as the state of the economy changes, and according to the characteristics of your customers), then it’s worth pricing your software just under a threshold rather than just over it. (p.45)
  • If Starbucks can de-commodify coffee and charge $4 for coffee beans and hot water, if Stormhoek can de-commodify grapes (the only wine maker I know of who sells branded G-Strings), and if Perrier can de-commodify water, then you can certainly de-commodify the complicated software application that you have created. (p.48)
  • The mere fact that customers could try out your software, if they wanted to, transmits a strong signal about its quality. (p.49)
  • At the very least, you need to be careful, and make sure the free version is good enough to be useful, but not so useful that it cannibalizes paid-for sales. (p.49)
  • Network effects occur where the value to your customer of using your product increases as the total number of users increases. (p.51)
  • It becomes, therefore, extremely important to reach the tipping point as quickly as possible, and the ‘free’ price point is a good way of doing that. Of course, once you’re past the tipping point you’ll need to make money from your product, without losing users. (p.52)
  • When choosing your pricing model, here are two recommendations. Firstly, be boring. Secondly, license your software as your customers expect it be licensed – fit in with their business model.(p.58)

What your price says about you (and how to change it)

  • Prices are never neutral. They send signals. For example, a high price can signal that you have a quality product. ... If your competitors are selling software at $10,000 a seat, and you’re selling yours at $100, then that says something about you. Of course, you might be saying ‘game changing’, but your customers might be hearing ‘toy’. (p.60)
  • Whatever price you choose, the signals it sends need to fit in with your brand, and your brand needs to fit in with your reality. (p.61)
  • You’re never going to know if you’ve chosen the exact right price or not, but you should experiment once you’ve set your initial price; not experiment in the scientific sense of forming a hypothesis, changing a single variable, and accepting or rejecting the hypothesis, but in the sense of changing something and seeing what happens. (p.62)
  • It’s not what your customers say that’s important, it’s how they behave. Whenever you make a price change, pay close attention to what your customers do. If they stop buying, rethink. (p.64)

Monday, October 24, 2011

Skimming : Smart & Gets Things Done

Smart and Gets Things Done: Joel Spolsky's Concise Guide to Finding the Best Technical Talent

Hitting The High Notes

  • The formula for Fog Creek Software, the company I started with Michael Pryor in September 2000, can be summarized in four steps:
    Best working condition -> best programmers -> best software -> profit
  • So, why isn’t there room in the software industry for a low-cost provider, someone who uses the cheapest programmers available? ... Here’s why: duplication of software is free. That means the cost of programmers is spread out over all the copies of the software you sell. ... Or, roughly speaking, if you try to skimp on programmers, you’ll make crappy software, and you won’t even save that much money. (pp 3-4)
  • The fastest students were finishing three or four times faster than the average students and as much as ten times faster than the slowest students. (p.6)
  • The real trouble with using a lot of mediocre programmers instead of a couple of good ones is that no matter how long they work, they never produce something as good as what the great programmers can produce.(p.11)
  • The mediocre talent just never hits the high notes that the top talent hits all the time. The number of divas who can hit the F6 in Mozart’s “Queen of the Night” is vanishingly small, and you just can’t perform “Queen of the Night” without that famous F6.(p.12)
  • Sadly, this doesn’t really apply in nonproduct software development. Internal, in-house software is rarely important enough to justify hiring rock stars ... That’s why the most satisfying careers, if you’re a software developer, are at actual software companies, not doing IT for some bank.(p.16)

Finding Great Developers

  • The great software developers, indeed, the best people in every field, are quite simply never on the market. (p.20)
  • Think about where the people you want to hire are hanging out. What conferences do they go to? Where do they live? What organizations do they belong to? What websites do they read?(p.23)
  • One good way to snag the great people who are never on the job market is to get them before they even realize there is a job market: when they’re in college. (p.25)

A Field Guide to Developers

  • I had to agree with him: Peopleware is a great book. One of the most important, and most controversial, topics in that book is that you have to give programmers lots of quiet space, probably private offices, if you want them to be productive.(p.42)
  • If the office space is crowded, if the carpets are ratty and the walls haven’t been painted and there are posters up with pictures of rowing teams and the word TEAMWORK in large print, they’re going to have Dilbert thoughts.(p.48)
  • Basically, if you’re going to hire smart people, you’re going to have to let them apply their skills to their work. ... Developers want to be hired for their skills, and treated as experts, and allowed to make decisions within their own realm of expertise.(p.54-55)
  • The world of programming is very just and very strictly ordered, and a heck of a lot of people go into programming in the first place because they prefer to spend their time in a just, orderly place: a strict meritocracy where you can win any debate simply by being right. (p.55)
  • Most programmers aren’t just looking for a gig to pay the rent. They don’t want a “day job”: they want to feel like their work has meaning.(p.60)
  • If you start to hear complaints about salaries where you never heard them before, that’s usually a sign that people aren’t really loving their job.(p.63)

Sorting Resumes

  • We look for evidence that the applicant is passionate about computers and really loves programming.(p.69)
  • The fact that they took the time to learn about Fog Creek and wrote a custom cover letter just for us means that they have a lot of confidence in their abilities, so they’re applying to a select few employers, not bulk mailing a thousand. (p.70)
  • That said, years of experience working with programmers have taught me that programmers who can communicate their ideas clearly are going to be far, far more effective than programmers who can only really communicate well with the compiler.(p.71)
  • In this category we’re looking for evidence that a candidate is, well, smart, or at least the kind of nerdy brainiac who went to math camp. (p.72)
  • Another thing we look for on resumes is evidence that someone has gone through some highly selective process in the past. ... but getting into a very selective school does at least mean that someone, somewhere judged you using some kind of selection process and decided that you were pretty smart. (p.73)
  • so for the purpose of sorting resumes, difficult technologies tend to float you to the top, while claiming competence in, say, Microsoft Word tends to float you toward the bottom. (p.74)
  • For someone who is basically a good software developer, learning another programming language is just not going to be a big deal.(p.80)
  • If you’re hiring an architect or head developer— that is, the chief software engineer who is going to have to lay out the initial code and figure out how things work together—you probably want to hire someone with a lot of experience in the technology that you’re using.(p.81)
  • Don’t start a new project without at least one architect with several years of solid experience in the language, classes, APIs, and platforms you’re building on.(p.81)

The Phone Screen

  • The great thing about a phone interview is that it’s much harder to form these kinds of snap judgments; you actually have to listen to what the person is saying and decide if that corresponds to what a smart person might say.(p.84)
  • My phone interviews have three parts. In the first part, I ask the candidate to describe their career history and basically tell me about themselves. (p.85)
  • The second part of the phone screen is the technical problem. What would be a good data structure for a photo editor? (p.87)
  • The third and final part of the interview is letting the candidate interview me.(p.88)

The Guerrilla Guide to Interviewing

  • You should always try to have at least six people interview each candidate, including at least five who would be peers of that candidate (that is, other programmers, not managers). (p.93)
  • Each interview should consist of one interviewer and one interviewee, in a room with a door that closes and a whiteboard. (p.94)
  • It’s because it is much, much better to reject a good candidate than to accept a bad candidate. (p.96)
  • In principle, it’s simple. You’re looking for people who are
    1. Smart, and
    2. Get things done.
  • People who are Smart but don’t Get Things Done often have PhDs and work in big companies where nobody listens to them because they are completely impractical. (p.97)
  • People who Get Things Done but are not Smart will do stupid things, seemingly without thinking about them, and somebody else will have to come clean up their mess later.(p.98)
  • What should you look for during the open-ended questions?
    One: look for passion.
    Two: good candidates are careful to explain things well, at whatever level.
    Three: if the project was a team project, look for signs that they took a leadership role.
  • Most of the time in the interview, though, should be spent letting the candidate prove that they can write code.(p.105)
  • You see, if you can’t whiz through the easy stuff at 100 mph, you’re never gonna get the advanced stuff.(p.108)
  • A good back-of-the-envelope question allows you to have a conversation with the candidate that helps you form an opinion about whether they are smart.(p.116)
  • The optimal time to make a decision about the candidate is about three minutes after the end of the interview. Far too many companies allow interviewers to wait days or weeks before turning in their feedback. Unfortunately, the more time that passes, the less you’ll remember.(p.116)
  • Finally, if you do have to say no to someone, do it quickly and respectfully. You are, of course, under no obligation to tell people why they’re not the right fit, but you do have to tell them, and you have to do it promptly. It’s just common decency to let them move on to the next opportunity.(p.119)

Fixing Suboptimal Teams

  • The bottom line is that cleaning house, as long as it’s done all at once, can often result in improved morale.(p.130)
  • If you want to lead a team, a company, an army, or a country, the primary problem you face is getting everyone moving in the same direction, which is really just a polite way of saying “get- ting people to do what you want.”(p.133)
  • Intrinsic motivation is your own, natural desire to do things well. ... Extrinsic motivation is a motivation that comes from outside, like when you’re paid to achieve something specific.(p.142)
  • Management, in general, needs to set up the system so that people can get things done, it needs to avoid displacing intrinsic motivation with extrinsic motivation, and it won’t get very far using fear and barking out specific orders.(p.146)
  • The real trick to management is to make people identify with the goals you’re trying to achieve.(p.147)
  • Seriously, though, a method I’m pretty comfortable with is eating together.(p.148)
  • In general, Identity Management requires you to create a cohesive, gelled team that feels like a family, so that people have a sense of loyalty and commitment to their coworkers. … The second part, though, is to give people the information they need to steer the organization in the right direction.(p.149)

Sunday, October 23, 2011

Skimming : Eric Sink on the Business of Software

Eric Sink on the Business of Software (Expert's Voice)


  • An ISV creates, markets, and sells software products ... If you don’t have a software product, you are not an ISV. (p.3)
  • My name is Eric Sink, and I am a code-aholic. ... I like the smell of a freshly killed bug. (p.6)
  • Identifying all the opportunities for software products is like filling a barrel with rocks. We start by putting in the really big rocks like office suites and desktop operating systems. Soon the barrel is full and will hold no more large rocks. But smaller rocks can still be added easily. In fact, we have to add a surprising number of small rocks and pebbles before the barrel can be considered full. (p.9)
  • We’re geeks. All of our training and experience happens in a world where there are no grays. A digital bit is either one or zero, on or off, nothing in between. This binary thinking tends to pervade the way we look at everything, including business opportunities. But not everything in the business of software actually works that way. (p.11)
  • This takes a lot of versatility, and it explains why entrepreneurs are usually generalists, not specialists. We are the type of people who tend to be just a little bit good at everything, rather than very good at just one thing. (p.16)
  • The ideal business failure is one that leaves you with the ability to learn from what went wrong and try again. (p.18)
  • But as a bootstrapped small ISV, you also need to ask yourself whether the market is small enough. Small companies should stay out of markets that are big enough to be interesting to big competitors. (p.19)
  • Horizontal product markets are filled with the wrong kind of competition for you. The competitors you want are in the vertical markets. These markets are safe from the big companies like Microsoft. (p.20)
  • My favorite solution to this problem is to start out as a consulting company and evolve into an ISV later. In your first 40 hours per week, build custom software or Web sites for other companies. Charge them enough money to pay your expenses. In your other 40 hours per week, work on building your product. (p.26)
  • Like it or not, for many people the word shareware carries connotations of something that is “amateurish” or “unprofessional.” Even as some companies wear this word as a badge of pride, others avoid it for fear that it will scare away corporate customers. (p.43)
  • In any software company, it’s important to find a way to keep your 1.0 cycle as short as possible while still building a product that will generate revenue... The purpose of 1.0 is to help pay for the development of 2.0, and so on. (p.46)
  • You are an entrepreneur, so by definition, you are somewhat more of a risk taker than most. (p.66)


  • Instead of programmers (people who specialize in writing code), what you need are developers (people who will contribute in multiple ways to make the product successful)... as a small ISV, what you need are fewer people who are more versatile. (p.78)
  • Put your programmers on the phone to help a customer with a tough problem. Your product quality will improve as you expose programmers to the consequences of the bugs they create. (p.80)
  • As Joel says, “It is much better to reject a good candidate than to accept a bad candidate. ...If you have any doubts whatsoever, No Hire.” (p.101)
  • The “very best” people never stop learning. (p.103)
  • I believe that people tend to become better programmers as they write more and more code. I want to know how much code you’ve got behind you. (p.107)
  • Twelve years later, I think there is some wisdom in hiring people who have made significant contributions to an open source community project. (p.108)
  • I love building software, but SourceGear is not my hobby—it is my profession. We sell products to users. We have learned to value the needs of the users over our own preferences. (p.113)
  • Great developers don’t just make the product better—they make everybody around them better. (p.121)
  • Quite often, the reason we don’t learn from a mistake is because we’re too busy trying to hide it. (p.128)


  • Finding a product idea will probably require you to think exactly the opposite of the way you usually think. You need to focus on problems to be solved, not on technologies to be applied. (p.138)
  • The basic idea of positioning is that your product occupies a place in the mind of the people in your target market. You are defined by their perceptions of you.(p.148)
  • The big problem with avoiding competition is that you are also avoiding customers. The existence of a competitor indicates the existence of paying customers. If you can’t find anyone who is making money with your idea, you really need to wonder if there is any money to be made there at all. (p.156)
  • If you want to start a new business, don’t look for an idea that has never been tried. Instead look for someone who is serving real customers but not doing it very well. Find a way to do it better. (p.157)
  • The Pragmatists will buy your product only when they see other Pragmatists doing it. If this sounds like a chicken-and-egg paradox, it is. (p.162)
  • The Early Adopters like new things, and your product is getting older every day. (p.165)
  • Code that was written more quickly runs more slowly. (p.180)


  • I observe that buying software is closer to the “high-trust” end of the spectrum.(p.236)
  • Pricing and positioning are inseparable. Don’t bother trying to figure out your price point until you first figure out what position your product will have in the market. (p.249)
  • Product -------------------------------- Customer
    In order for the sale to occur, this gap must be closed.(p.265)
  • Moving customers is very difficult to do, especially for a small company with very little clout... Moving your product toward the customer is a lot easier. (p.272)

Monday, October 17, 2011

Skimming : From Airline Reservation to Sonic The Hedgehog

From Airline Reservations to Sonic the Hedgehog: A History of the Software Industry (History of Computing)

  • The software industry can be divided into three sectors: software contracting, corporate software products, and mass-market software products. (p.3)
  • Though there was no shortage of applicants, less than one-fourth passed through the initial screening and secured a job offer. The screening consisted of a three-day battery of psychological and mental aptitude tests that proved to be a fair predictor of programming ability. (p.39)
  • Contemporary estimates indicate that between 200 and 300 US insurance companies eventually used the package, many with multiple 1401s. Increasingly, users were becoming aware of the advantage of making their operations conform to an available package, rather than making a package conform to their historical bureaucratic idiosyncrasies. Only the biggest firms, such as Prudential, could still justify the assertion that they liked to do things their own way. (p.98)
  • Autoflow is better viewed as simply one example of an idea that was occurring more or less simultaneously to many people in many places. The only common traits among these individuals were an entrepreneurial streak and experience in the computer industry. (p.101)
  • Whereas videogame consoles were bought for a single purpose, home computers were bought for a variety of uses: for home offices, for small businesses, for educational purposes, and so on. But in practice most home computers ended up with game playing as their principal use. Games accounted for about 60 percent of home computer software sales. (p.276)
  • Even a hit game usually had a market life of less than a year, whereas a word processor or a spreadsheet program had an indefinitely long life and provided a constant source of upgrade fees. Hence, the appropriate business model for a producer of videogames was closer to that of the recorded-music industry than to that of the personal computer software industry. (p.281)
  • In 1986, Super Mario Bros. 3 reportedly grossed $500 million, more than any
    Hollywood film apart from Spielberg’s E.T. (p.285)
  • Interestingly, for the PlayStation there was no “killer app” comparable to Mario Bros. or Sonic the Hedgehog. Though games such as Virtua Fighter and Tomb Raider (Lara Croft) sold in the millions for the PlayStation, they were also available for other platforms. The PlayStation succeeded because Sony recognized the changing demographics of videogamers. The videogame enthusiasts of the 1980s—the 6-to-14-year-old males who had grown up with Ataris, Colecos, and Nintendos—were now in their mid twenties, with spending power far greater than an adolescent’s. (p.288)
  • Printed encyclopedias had never really sold on the basis of content; their sales had been based on intangible prestige and authority—values not highly appreciated in the world of multimedia CD-ROMs. (p.294)
  • Nonetheless, if one wants to emulate the success of another institution, history is usually all one has to go on. Though history cannot provide prescriptions, it can certainly provide insights (p.303)
  • Proportionately, the R&D spending of software companies is comparable to that of the pharmaceutical industry; however, R&D plays markedly different roles in these two industries. In the pharmaceutical industry, much of the R&D takes place in university and industrial research laboratories, and field trials are directed by PhD-qualified scientists. In the software industry, most of the R&D is done by youthful programmers, usually not trained past the bachelor’s degree level, who crank out code in an intuitive but effective fashion—R&D with a small r and a large D. (p.308)
  • Manpower training has been a major strategy of such emerging software nations as India and Ireland. However, the evidence so far suggests that it is likely to result in an industry performing “off-shore” software development for the benefit of US-based multinational corporations. This is a new variant of the old business of “body shopping”, not the rise of a leading-edge software products industry. (p.311)