low post

The other day, at #LeanCoffeeTO, we discussed pricing.  This is a subject near and dear to my heart as it is something I spend a lot of time on and have realized, much to my chagrin, there is very little science to this and a lot of art.  We decided after our meeting, with lots of great ideas, best practices, stories, pitfalls, etc that we should all post our approaches and practices to pricing in order to formulate a more extensive list for reference.  I’m doing it here on my blog with the hopes that I might actually generate some more discussion to a larger audience than our weekly meetup.  Here I go…

Working for an Enterprise software company with a mature application and a lot of long standing customers puts some specific constraints on the exercise of pricing (or re-pricing and/or developing new but related product pricing).  As such, many considerations that I have to make are not relevant to those of you developing entirely new products or services and trying to figure out how to price them for the first time.  Still, I think a lot of factors are the same, regardless of where you are in your product lifecycle.

This will be a list in no particular order that I may choose to re-order when I’m finished but I may not depending on how much time I have.

• Anchoring – always be aware of the power of anchoring a number in people’s minds.  If it’s the first time you’re introducing pricing for your product/service, then the first thing you put out there will become a strong anchor in the minds of your users and customers.  Like it or not, and unless you creatively re-invent your product at a later date, the first price is the baseline for comparison going forward.  Often, the anchor is set by someone else so of course you must also be aware of that in any pricing exercise.
• Customer value – pricing based on value is extremely hard but important to attempt in your analysis and research.  I believe there are really two types of value approaches: (1) The perceived value of the customer and (2) a more quantifiable value based on a ROI style of analysis.  I recommend considering both of these when developing pricing
• Cost – of course it’s imperative that you understand your costs to develop and deliver your product or service.  Still, I personally don’t recommend taking a full “cost-based pricing” approach, especially if you’re selling a web/mobile/software application.  Just make sure you understand your costs to build and support but remember your customers don’t care how much it cost you to build it.
• License/Packaging/Delivery models – these are all important factors in your pricing development.  I suppose they are less about coming up with the price and more about providing some options to create different price points.  For example – pricing the base offering and layering on features/options for an additional cost; bundling options; tiered pricing based on volume or length of commitment, etc…
• Competition and market forces – obviously
• Branding – you must know ahead of pricing (and this goes back to the value concept above) what type of brand you or your product is.  Pricing is a major component of branding so be careful here.
• Product market – you must understand the type of market you are in for your specific product or service and the existing price points and pricing models being used in that space (remember anchoring)
• Pricing market – similar to “product market” you must also understand the price points and models already established in the larger, more general market.  For instance, app stores have indirectly set ranges for mobile apps, regardless of the specific product type and/or value.  This is certainly not always the case but it must be considered.  In my experience in the Enterprise Software space, when looking at subscription-based pricing for a SaaS products, Salesforce.com has really established a precedent and must be factored into pricing decisions for other SaaS products whether they compete with Salesforce.com or not.  Again, this is very much due to anchoring and the creation of a perceived price point that users are willing to pay based on a different product/service they already pay for (or have seen and decided not to pay for).

This is not an exhaustive list but hopefully provides some useful ideas for consideration, especially if you’re doing pricing for the first time.  Please forgive the fact that many points are strongly related, verging on being repetitive.  I’m also hoping to learn from those of you who wish to start some discussion around this expansive topic.

It started off with a simple tweet and suddenly I’m organizing a huge startup event in Toronto…

Back in April, I was planning my next trip out to Actuate’s HQ in San Mateo and my attendance at the web 2.0 conference when I came across Startup Weekend Silicon Valley.  I started reading and, while I couldn’t stretch my trip and leave the family for an extra few days to attend, I thought to myself, why hasn’t this event come to Toronto yet?  So I tweeted that same question.

Next thing I knew, the folks at Startup Weekend were in touch to let me know they wanted to do a bunch of Startup Weekends across Canada – covering all the major cities.  Now I’m not going to bore you with all the details that followed.  Let’s just say that I met the Startup Weekend crew in San Francisco at web 2.0 and here I am, organizing Toronto’s first (well, not quite but that’s another story) Startup Weekend.

Frankly, I’m surprised it’s taken so long to get here.  Toronto has a vibrant tech and startup community and given that these weekends are going on all over the world and gaining tons of momentum, why didn’t someone jump on this before me?  Perhaps it’s because there’s a perception that we already have these type of events in this city.  If that’s the case, I’d have to disagree.  While we have many great events in Toronto covering this space, there is nothing following quite the Startup Weekend model.

Here’s my plug for the event… I hope to see you all there so please check out the site, register and come out with all your great ideas and skills.

Startup Weekend recruits a highly motivated group of developers, business managers, startup enthusiasts, marketing gurus, graphic artists and more to a 54 hour event that builds communities, companies and projects.

Founded in 2007 by Andrew Hyde, the weekend is a concept of a conference focusing on learning by creating. It is known for its quick decisions, ‘out of the box’ thinking (oh no, the buzzwords are attacking!), unique facilitation technique and letting the founders show what they can do. The program has already met with success in over 100 cities all around the world.

The participants that attend a Startup Weekend decide what they want to tackle over the weekend and come out at the end with several developed companies or projects. Attendees are responsible for bringing desire and passion to the project and walk out of the room with the task at hand, in a short 54 hours. Sound intense? It is.

Startup Weekends continue to build momentum, happening in cities across the globe every week. Toronto is holding its first Startup Weekend September 24-26, 2010 at Ryerson University. The event will be limited to approximately 100 participants and expects to be sold out quickly.

If you read it here and want to attend, use this discount code (lowpostSWTO) to register for a great price.  Yes, there is a cost – the event is 54 hrs long and covers meals and drinks along with prizes and other great stuff.  Startup Weekend is a non-profit and we only look to cover costs and make the event great.

It’s also worth noting here that Startup Weekend has no rights to any ideas, products or companies that come out of the weekend.  We’re only interested in getting people together to build cool stuff and see where it goes.

Follow @startupwkndTO and search #swtoronto for news and updates about the event.

I’m attending the Web 2.0 Expo this week in San Francisco.  Every year, there are a few themes.  Last year it was definitely Twitter and interestingly, even with the massive growth of Twitter since last year’s conference, it feels less relevant this year (or maybe it’s just yesterday’s news).  The big themes this year are: the lean startup movement, mobile, and platforms (everyone likes to say they are developing a platform).

I attended the lean startup intensive session on Monday curated by the man behind the movement, Eric Ries (check out his blog for all info and material on the movement).  I decided to attend this over other sessions because I’m passionate about startups but also because I truly believe that the lean principles can and should be applied inside larger organziations, like my current employer.  I’d like to think that I can apply some/all of these principles in my job now, developing software products and features for Actuate.  Interestingly, while the philosophies make perfect sense:  Define product/market fit, get close to your customers, constantly validate your product with customers and through data, pivot as much as you can or as much as necessary, etc (you can read them all for yourself – this stuff is all over the web), there is little to no information on how to build these practices inside of larger organizations.  I strongly believe that lean principles make perfect sense for defining and building products, regardless of the size of the organization, but in practice, being “lean” is a difficult challenge when many pre-existing structures, processes and bureaucracy are already well entrenched.  These are challenges at most large organizations, at least any that I have experienced through direct employment and through consulting.  As we all know, changing an organizations culture is next to impossible and needs to come from the ground up and likely from the beginning.  My personal challenge will be to do my best to apply the lessons learned from this movement and effect as much internal change as possible inside my organization to work in this manner.  In a startup, it’s much more straightforward, although the challenges are just different. Continue reading »