By Michael Woloszynowicz

By Michael Woloszynowicz

Wednesday, November 16, 2011

Price Doesn't Always Matter

Don't get me wrong, pricing is an important part of a product strategy, particularly in the consumer goods sector, but it doesn't always matter. I see lots of startups wrestling with how to price their newest product, often pricing too low or even taking a freemium approach, all in the hope of acquiring a large initial base of customers.

Because pricing is such a large part of our daily purchasing habits (Groupon?), we have a natural inclination to believe that the it's a major decision for our own startups. The common belief is that pricing follows a traditional economic supply and demand curve, with a lower pricing yielding a higher demand and vice versa. While this is largely true, focusing on this model alone ignores a myriad of other uncertainties facing an early stage startup.

The problem with fixating on price at an early stage is that you're bound to get it wrong. Whether you're wrong on the high or low end is irrelevant, what's important is that an obsession with price can lead to wasted time and energy. Expecting to come up with an optimum price before your product reaches its first set of customers is nothing more than an exercise in futility.

Where energy needs to be expended is on discovering the true barriers to adoption. Price is only one barrier, and within a particular rage it can be a minor one at that. To come up with a list of adoption roadblocks, an intimate understanding of your target market is first needed. A study of your ideal client may reveal any of the following:
  • A high resistance to change, perhaps due to high switching costs from their existing solution
  • No clear way to reach them, perhaps leading to high acquisition costs
  • Technical knowledge barriers
  • Trust, security or privacy concerns
  • There's risk in using your product, will it be hard for them to get out?
You'll notice that if any of the above were to hold true, pricing wouldn't even become a factor in the buying decision. It's these sort of deal-breaking factors that should serve as the focus of your attention at the outset as they can be addressed through product strategy, features, and website copy. The price elasticity of your product is something that can be validated through experimentation and A/B testing once the product peaks the customers interests and any hidden concerns have been eliminated. Until that point, you're safe to choose a value based pricing strategy and move on. Resist the temptation to begin with freemium pricing (unless your type of product is highly conducive to it) as it often fails to give you an indication of your product value in the eye of the customer.

Despite the title, pricing is important for your product in the long-term, but its significance only comes to play if there are no other forces working against you. Focus your efforts on flushing out these hidden barriers to growth and leave the pricing debate for a later date.

If you liked this post please follow me on Twitter for more

Saturday, November 12, 2011

Under-Appreciated Engineers and the Curse of Usability

The life of an engineer is not an easy one. We're expected to translate ambiguous requirements into a concrete, timely, and scalable solution that satisfies a wide range of stakeholders. We venture into the unchartered territory with an ever growing array of technologies and infrastructures to choose from, never knowing what direction the product will take in the future.

While such challenges plague us on a daily basis, the really depressing part is that only a precious few people will ever appreciate the effort that went into it. Often not your boss, and certainly not the end user. 

The superficiality of human nature leads people to appreciate the physical aspects of the product rather than the beauty that lies within it. There's no better example of this than Apple products. While Apple garners constant adulation for the beauty of its products, few praise the engineering effort that went into every detail of a MacBook Air or iPhone, and bringing the designers vision to life through a physical and functioning unit. This effect transcends technology products and is equally evident in an industry such as construction. When an important or influential building is erected, it's the architect that garners all the attention while the engineer that is responsible for the lives of its inhabitants remains largely unnoticed.

From a technical product standpoint we suffer from a curse of usability. The simpler the product's interface the more muted the engineering effort appears, when in fact the opposite is true. The simpler the interface, the less work the user must do, the more work the engineer must do to yield the desired result.

That's not to say that engineers never get any attention, they do, but it's rarely the kind we want. Engineers are usually brought to the fore as soon as something goes wrong. If that very building collapses you can believe that the engineer will become the star of the show.

So what's my point? Well...

For those that are pursuing a career as an engineer of any sort, you'll have to develop a good degree of meekness. You'll have to make sure that you're pursuing it because you love it. You love the daily challenges, the ambiguity, and you're comfortable not always getting the praise you deserve.

For the companies out there, I urge you to foster a strong engineering culture where upper layers of management have the technical knowledge to appreciate the work done by your engineers. Companies like Facebook and Google attract lots of brilliant engineers for this very reason. If something goes wrong, don't be quick to blame the engineers. Remember that a majority of failures stem from a management problem rather than a technical one.

For the masses, I ask that you look beyond the surface of the product and become curious about what it took to make it work. Remember that simplicity often masks a host of technical obstacles.

For the engineers out there, I urge you to not live in a bubble, surrounded only by your own set of challenges. Reach out to your fellow engineers, ask them what they're working on and praise them for the interesting problems they've solved. You're in the unique position to understand and relate to their challenges. Remember that they'll do the same for you when you need them.

If all this fails, appreciate that you are creating something out of nothing, something that is hopefully used by and changes the lives of a large number of users. There will always be a demand for your craft, even if the appreciation of it is not always what you'd like it to be.

Cheers to all the engineers out there.

If you liked this post please follow me on Twitter for more.

Sunday, November 6, 2011

CoffeeScript Means Giving Up on JavaScript

While many of you will probably disagree with me, I find the trend towards writing in languages that compile to JavaScript somewhat alarming. The most notable of these languages CoffeeScript, and it's one that has gained a good degree of traction over the last year or so.

While I like and applaud the intention of these languages, I question their necessity and worry about the knowledge gap they create. More importantly, they all fail by requiring that you be an expert in two languages. Let's face it, you can't just program CoffeeScript without knowing JavaScript, unless you're willing to defer debugging to someone who does. If we're already willing to learn both languages and then spend time reading and debugging compiled JavaScript, why not just write good JavaScript from the start? For the extra effort you'll make learning CoffeeScript and its idiosyncrasies, why not put it towards really learning JavaScript?

The problem is that many programmers are turned-off by the lax nature of JavaScript and translate this into a shortcoming when writing large JavaScript applications. What you're really doing is giving up on a language that is brilliant for that very reason. Sure JavaScript has its share of problems, but they are all issues that are workable given enough knowledge and the use of a proper framework.

While frameworks help, some also serve to propagate this JavaScript stereotype. jQuery is a perfect example, as it does a brilliant job of eliminating cross-browser inconsistencies and makes DOM manipulation a snap, but does little to improve the overall structure of your application. A relatively small number of companies have sought out frameworks that aim to address the spaghetti problem, while the rest quickly realize that their jQuery code has become an unreadable mess. The reason these things happen - and it's the source of most problems with JavaScript - is because people simply don't know JavaScript. I've written at length about the JavaScript knowledge gap and the ad-hoc school of learning so I won't dwell on it here, but I urge you to ask yourself whether a move to CoffeeScript is sign that you've given up on learning it properly? Is it a problem with JavaScript or a lack of understanding?

As of writing this, I've written more lines of JavaScript than I care to admit. In fact our entire web front-end is written in JavaScript, and not once has our team had problems with maintaining our JavaScript code. In fact, despite our massive JS code base, we rarely have problems caused by the very things that CoffeeScript aims to eliminate. The main reason for this is that we've enlisted the help of a framework that brings structure to our application. Our choice was Dojo but you could also choose Require.js (a close relative of Dojo's class system), backbone.js, the Sencha framework, and many others that you can use in combination with jQuery (if you so desire). The other reason is that we've forced our developers to gain a deeper understanding of JavaScript and built a set of best practices that everyone follows which help to produce a consistent and high-quality result.

Before you delve into the world of "compline to JS" languages, I urge you to check out some of these structural frameworks, pick up a copy of JavaScript the Good Parts, and re-evaluate your decision. If after all this you still feel that the syntactic advantages of CoffeeScript et al. warrant the move, then by all means dive in. I simply ask that you enforce a good degree of JavaScript knowledge from your coworkers, and make the move for the right reasons, not because you're running away from JavaScript. JavaScript is the language of the web, and its understanding is further jeopardized by delegating another language to write the code for you.

If you liked this post please follow me on Twitter for more.