Tools of the Trade

In the process of developing our new service we are morphing from a traditional telecom software company to a more agile web/services focused organization.

We’ve introduced our own version of extreme programming, a move which required us to adopt new processes and new tools for managing the product life-cycle.

Internally we are now working on multiple small projects.  Each project consists of a focused feature set, and a master project coordinates the various sets.  Instead of using goold old Microsoft Project, we are now using 37Signal’s Basecamp as our primary project management system.

Wonderfully simple, Basecamp enables us to quickly set up projects, monitor progress, and share information.  We have recently started using it to share project information with external business partners.  We use writerboards to make sure everyone – from marketing to R&D to QA and support – knows what the shared vision is.

Whereas Basecamp is used for project tracking, task management and milestone management, most of the information we put in the system is in the form of references to either our bug/feature tracking system (phpBugTracker) or to our internal Wiki (PmWiki).  This ensures that we don’t duplicate information across the various systems, and that we keep critical information in-house.

The combination of Basecamp, BugTracker and PmWiki gives us the flexibility we need in terms of sharing the right informatino with the right stakeholders.  Management, marketing and R&D each have their own information sources, with overlapping interfaces.   This enables everyone in the company to know exactly what is happening and what the next steps are.

For marketing/management we have started using a mind mapping service – Mindomo .  Using mind maps we can easily capture concepts, ideas and relationships.  Since we are starting with a brand new service offering, there are many directions in which the service may evolve.  This is not only true on the feature/technical side, but also on the positioning and business development side.  A mind map enables us to capture the various options and directions, and later on to chart the course we want to take.

Essentially, all ideas get captured in the mind map.  They can be traced to their origin, and can also be inter-connected to other points on the map.  We also use the mind map to track and identify potential partners and customers, and to related business development, marketing, and technical activities – which partner requires which feature set, which sales opportunities will be enabled by developing certain items, etc.

I find mind maps quite addictive in their simplicity.  No useful idea gets lost, and at the same time I can get an accurate snapshot of “where we are”.

It is quite amazing to consider that just a few years ago your software and product management tool choices were limited, expensive and time consuming.  Today we are using one paid-for SaaS tool (Basecamp), one free SaaS (Mindomo) and two open source in-house tools (PmWiki and BugTracker).  On their own they are good low cost solutions.  Together, they are a company-changing toolset, delivering exceptional value and easily supporting our new initiatives.

— Oren

When is “Just Good Enough” good enough?

Pragmatic Marketing recently published an article describing the “just good enough” product planning concept.   In a nutshell, the concept says that you should always figure what what is “just good enough” for your customers and focus on delivering products and product features which are just good enough for your market.  

Like all consultant-based approaches, this one is also easily described using a magic quadrant and a simple graph.  Unfortunately, while the concept seems to make lots of sense, applying it in real life is, well, tough.

For instance, before you can determine what is good enough, you must clearly define your target market and your customer persona.  In other words, “just good enough” is always relative, and is always on the move.  What is good enough for a Ford buyer is not good enough for a BMW buyer.

One seemingly obvious example of a company which has embraced the “just good enough” principle is Google.  When you look across their entire product base, it is clear that they are not the technology leader in any category.  There are better search solutions, better advertising platforms, certainly more feature rich email solutions, etc.  Just looking at their products, one is tempted to say that they had cracked the “just good enough” formula, and are applying it left and right with great success.

However, I would argue that Google is doing anything but “just good enough”.  Applying “just good enough” implies that at one point someone at Google took a look at GMail and said “enough, we don’t need any more features, this is good enough”.  And at that point all the developers simply junked the hundreds of features they were considering, feeling disappointed that they are not going to deliver the most feature-rich platform out there.

This, of course, is bull.  Google’s chief design principles revolve around simplicity and clean interfaces.  Its products are not devoid of features.  Their simplicity IS the feature.  GMail is not a crippled version of Hotmail, and happens to be “just good enough”.  It is a BETTER (IMHO) platform than Hotmail, and delivers excellence and market leadership on dimensions other than just feature-count.

In the business strategy world we’ve always used “just good enough”.  It is called “show me the money” or “if we build it, will they buy it?”  At the corporate level there is nothing new here.

At the practical level, “just good enough” deserves to be R&D’s guiding light.   Product managers, marketers, developers and the rest of us, are always interested in delivering the best possible product.  This is natural. 

However, given resource constraints, time to market needs and just our incapacity to hold 30 meetings a week, there

Right now I am in the midst of planning a new product offering.  With a core product idea, this is the point at which the product can develop in many different directions.  New ideas pop up all the time, each one is supposedly better than the last one.  Feature creep is upon us.  The product plan grows horizontally (new features, new ideas) and vertically (“we simply cannot launch until we optimize this and solve that!”) 

It is at this critical point in time that I use the “just good enough” principle as a practical tool.   All members of the product planning team are reminded daily of the priorities:  Launch, launch soon, and launch fast.  Make it work.  Sort of. 

Mind you, we are talking about alpha and beta launches.  The risk here is that feature creep and general defocusing lead to delays and (while adding more features) to a more buggy product. 

Each team member is encouraged to keep a journal of ideas that can deliver value, but that currently go beyond what is “just good enough”.  Personally I use a Wiki system, as I find it the most flexible tool out there to record, grow and expand ideas.

Ideas get written down even though it is clear to everyone that some of them will never get implemented.  Still, it is better to spend 10 minutes writing down an idea than spending two weeks implementing it, only to find out nobody cares about it.  Periodically ideas get reviewed, and, depending on what is “just good enough” at this point in time, may get incorporated into the product plan/roadmap.

So here’s my 2 cents:

- Clearly define what is “just good enough” relative to where you are in the product life-cycle.  Define your most critical business and marketing goals.  Anything which does not contribute greatly to achieving these goals is distracting and resource consuming.

- Log every idea, bug, comment for future reference.

- Establish clear milestones for re-evaluation.

- Learn to embrace less-than-perfect solutions.  Fight the urge to make your service respond in 0.01 millisecond, when customers are happy to accept a 5 second lag.  Apply your resources where they make the most customer impact, not product impact.

- …don’t spend too much time posting to blogs (Actually, this is a serious comment.  Blogs have become the #1 time-sucking activity for me.   I now have specific time slots set aside for feed-reading…)

— Oren

Good News, Bad News

We’re getting ready to launch a new service offering.  Whereas our existing Service Delivery Platform product line is currently targeted at the Chinese market (see Shanghai Mobile Announcement), our upcoming service offering targets the rest of the world.

 As we’re still pre-alpha, I cannot discuss it in detail (hey, I just lost most of you).  I’ve been spending the past few weeks travelling, meeting with potential partners, potential customers and most importantly with people whose opinion I value.  The result of this activity is a Good News, Bad News situation.

The good:  Everyone is excited by this new offering.  It seems to resonate with current market trends, and bridges a gap in the current value chain.

The bad:  There was not a single person I had met who did not ask me this question:  “Is it legal?  Can you do it and get away with it?”. 

And there you have it.  It all hinges on that seemingly simple question.   Often product managers and marketing executives in general tend to be so taken with the opportunity, so excited with the prospect of real product innovation, that they tend to ignore this often fatal question – am I allowed to do this?  (If you’re Google or Microsoft you may ignore this and just refer to your legal team/department/army).

Oh well.  I’m meeting the lawyers on Monday.

 — Oren