Posts Tagged 'SaaS'

Product Planning Series: Project Management

[tweetmeme source=”chenelaine” only_single=”false” service=”bit.ly”]
This is the fourth post in my Product Planning Series.

Bringing up a new web app is much more than a technical project management effort.  Any new product or service development program is a massively interdisciplinary exercise.  In order to have a successful outcome all affected constituencies will need to be involved in developing the program plan, so that key milestones and dependencies are identified from the get-go and actively and aggressively managed so that there will be no surprises halfway down the line that will result in a significant project delay.

Here are some of the interdepartmental milestones that need to be worried about for our consumer SaaS example.

On the customer research / persona development side:

  • Product discovery research done – target persona(s) chosen and fleshed out
  • Needs, wants and expectations fully understood for target personas
On the business planning side:
  • Finalize pricing structure
  • Finalize channel strategy (for our example this is direct to consumer, which makes life very simple indeed.)
  • Where applicable, develop ROI analysis for target customers (this will be used by product marketing to convince prospective customers to adopt the product or service)
On the product planning side:
  • Product strategy fleshed out – this basically describes the product concept that solves customer problems
  • Basic product roadmap developed with some idea of phasing of which problems to be solved when and how over the next 12-24 months (I like to make a 1-2 year actionable roadmap and a 5 year vision roadmap)
  • First pass definition of minimum viable product (MVP) complete (this is a hypothesis based on customer learnings to date)
  • User stories developed (this usually requires a second round of customer research) – a paragraph per story
  • Key user workflows fully mapped out at least to the flow chart level (this is particularly important if you are developing something for a target user persona that is not readily relatable by your program team.)

On the design side: (these milestones are specific to my consumer SaaS example. Some other day I will write a different post for hardware products.)

  • Determine high level navigation architecture (what are the organizing principles of the information and actions you can take on this web app?
  • Wireframe key pages to illustrate workflow
  • Design a few example pages to “put the breadcrumbs closer”

On the technical side:

  • Development platforms chosen
  • Server side architecture design finalized
  • Server set up, ready for development
  • First proof of concept with rudimentary UI showcasing any high risk items that needs to be investigated (e.g. if you were testing out a brand new private video streaming service that has just come on the market)
  • Key third party technologies integrated (e.g. shopping cart, knowledge base, etc.)
  • Intermediate internal releases as parts of the app comes up for testing
  • First instantiation of the MVP (minimum viable product) with a relatively complete user experience, released for beta testing
  • First release of the MVP (start to charge for the service!)
On the customer research side:
  • First set of product discovery interviews done, ready for persona development
  • User workflows vetted with users at the wireframe/storyboard level
  • Customer Advisory Board (CAB) assembled, ready to advice program team on features and benefits
  • Continuous testing of intermediate releases with CAB members
  • Usability study of implementation for key workflows (Do some in-house lab testing with fresh subjects – not CAB members, and do some across a broader audience with services such as www.usertesting.com)
On the product marketing side:
  • Design and develop content and assets for landing pages, conversion pages, etc
  • Develop PR strategy to get the word out (for this example, work should be done well in advance to get key blogs to cover the launch of the web app.  Facebook page should be set up with appropriate content and prepopulated with fans drawn from the early tester community.)
  • Decide on, and execute, any one-time campaigns to promote the release (e.g. email campaign)
  • Develop any product collateral (e.g. quick start guide, user manual, video tutorials)
  • Update any corporate web pages ahead of time for a coordinated launch activity
On the business development side:
  • If applicable, business development activities to land partners will need to carry on in parallel with all these other activities. For instance our music app for small children might benefit from having Suzuki string teachers on the roster to provide expert answers.  The business development activity for this app would then involve recruiting and engaging these partners.
On the customer support side:
  • Determine customer support policy – first tier, second tier, email / phone coverage, languages and hours supported, turnaround time, etc.
  • Develop on line help / FAQ (this could be done entirely via a searchable, hierarchical knowledge base)
On the legal / regulatory side:
  • Develop end user license agreements / terms of use
  • If applicable, obtain regulatory clearance if the product or service requires it (our example does not require anything, but a medical site that, say, provides diagnostic guidance to various illnesses might have to look into FDA 5(10)k)
There is a lot of work that goes into developing a new business and many different constituencies are involved.  A little bit of planning up front goes a long way towards helping to make the program a success (and to minimize the level of stress in the development process).
Advertisements

Product planning series: who, what, why, how

[tweetmeme source=”chenelaine” only_single=”false” service=”bit.ly”]
This is the second post of my Product Planning series (which uses a new web app as an example to illustrate how you go about planning the release of a new product or service.)

In my last post I outlined some of the questions that you should ask to establish a business case for your new product or service. Once that’s done, it’s time to define who you are building the product for and the problems they face, what your proposed solution looks like, why you think it is better than anything else out there, and how your solution will work to solve these customer problems.

Who
The first question some people ask is: why segment and target? If one does a wonderful job with product development, shouldn’t the product sell to anyone who might find a use for it? My answer is this: it is not possible to develop a wonderful product without knowing who you are designing it for.

Let’s say our web based B2C consumer SaaS offering is an educational site for children that focuses on advancing the musical education of kids who are learning an instrument.

Right away we can see that the buyer (a parent, grandparent or teacher) is different from the user (a student). You will need to build a buyer persona and a user persona. The buyer (parent) wants the child to learn. The user (child) just wants to have fun. To be successful the product must both educate, to meet the needs of the buyer, and entertain, to satisfy the wants and expectations of the user and to ensure stickiness and compliance in product usage.

If the word “persona” is new to you, Pragmatic Marketing has an excellent article explaining the persona concept, and Scott Sehlhorst has a great article on this topic. You can also consult my post on using ethnographic techniques to develop personas.

The purpose of developing the persona is to use the target buyer and user to help decide what to build and how to present it. What age group are we targeting – do you need to cater to the pre-reading crowd? How high do we go in the age bracket? These affect the user interface and use cases because clearly a 15 year old violinist playing first violin in a youth orchestra has vastly different needs and wants than a 5 year old violin novice working on basic bowing techniques.

Persona development goes far beyond demographic information and goes deep into situational scenarios. What is it like living in the households of these music students? What is their daily schedule? How long do they spend on music practice each night, and for how many nights a week? When do they practice music? How involved is the parent? Are they distracted by their siblings? What parts are hard to learn? What are the objectives of the child and what problems does he or she face? What are the objectives of the parents and how do they measure their child’s success?

A good persona provides demographic and psychographic information, as well as additional information about the attitudes and motivations of the persona in the area of product use. It is well worth the initial investment to develop a good set of personas, then clearly delineate the problems they face. It will help make development more efficient down the line and help you develop a great user experience that is tailor made to your target end users.

What
Once the buyer and user personas are defined, and their problems are well understood, it’s time to figure out what the solution to these problems might look like. For example, it is very hard to motivate a young child to learn all those pesky Italian musical terms. Perhaps an on line memory game might help them remember those terms. Another example is that the child may need to work on posture. Perhaps a video feature that allows the parent to take a video with their cell phone, then upload to a server and share it privately with the teacher might help. A third example is that the child has forgotten the correct technique 3 days after the teacher demonstrated it. A video snippet of the lesson might just do the trick. And having this all in one place encourages usage and compliance.

As a product team comes up with solutions, there are invariably way more ideas than what would fit in a desired timeline. Here is where the persona will be useful: the product team can use the persona to help them imagine what is of the most use to those personas, and develop a release roadmap where features that deliver the most benefits and value are released first, followed by other features that either broaden the offering or offer secondary benefits.

Why
Many wise product and startup people, including the folks at Y-Combinator, have commented on the need to focus on the customer, not the competition. This is very true. However that doesn’t mean you get to punt on doing a thorough competitive analysis to understand exactly what is out there in the market. This helps you in several ways:

  • You can check to see if your solution really solves an unmet need. If to your chagrin you find something that solves the problem quite well, it’s better to know sooner than later so you can pivot to solve a different problem that REALLY represents unmet needs.
  • You can learn from the successes and failure of other people who were in the market before you.

With a good understanding of the competition you are well poised to articulate your competitive advantage which is necessary for developing an actionable and meaningful positioning statement.

How
Interestingly, many technology startups start with the “how” as the basic premise for starting a company. Someone comes up with a brave new technology, develops a prototype for it, gets it to work, falls in love with it, then sets off starting a company with a field-of-dreams business plan.

That works sometimes if the technology is really world shattering. In consumer SaaS, the technology itself is sometimes commodity software. So for those types of products, the “how” comes only after having figured out the who, what and why. The “how” is concerned with how to actually implement the solution. For this example, you would pick the technology platform to develop your new site on – fielding considerations such as open source versus proprietary platforms (my vote: Open source), database of choice (I like MySql), programming platform (for complex web apps: Java EE back end with Javascript or HTML5 front end; for quick hacks, I like Ruby on Rails). You will need to make decisions early on about hosting and server care and feeding too: certain platforms bring a hefty server side license fee and you will need to account for it in your projected server fees and expenses.

Once the platform is picked, you can now work on defining and designing the product in detail, staffing up for success, and executing the plan to bring your offering to market in the desired timeframe.

Open source v. Microsoft

[tweetmeme source=”chenelaine” only_single=”false” service=”bit.ly”]
Lately I found myself in the middle of a discussion with a client about which web platform / architecture to choose for a new SaaS project.

The web app itself is eminently doable on any platform, and is not all that scary from a technical difficulty standpoint.  The client is very much adopting an MVP approach and there is buy-in across the board to tightly control what gets in for V1 so there won’t be huge feature creep.   While scalability is a consideration they believe they will roll it out in a measured pace in the initial months, so it is not necessary to plan for, say, 5 million uniques and 15 million page views in a month – they have no plans to push the traffic while they are in learning mode.  So there is time to learn and adjust once the app is launched.

If there is no development history to the project, everything could have been handled with open source technologies.  Drupal could be used as the content management system for the marketing stuff, Java / Ruby / Python or even php could be used on the server side, and one could use MySql or Postgres for the database.  One never has to worry about exploding server side license fees if one stays away from IIS, .NET, Microsoft SQL server and stuff like that.   Open source platforms are great if you have a pronounced need for speed. There are many reusable open source code libraries one could leverage.   Lastly, all the cool kids want to do Ruby on Rails these days and it is much easier to recruit for a Ruby developer than a C# developer.

Alas, there is actually quite a bit of history that complicates things. First of all, there is a legacy Microsoft SQL database with an existing schema, much of which is applicable to this application, and it would be highly advantageous to be able to migrate it instead of having to redo it all in another database.   So moving away from MS SQL doesn’t seem to be advisable.  Second, and more importantly, this company is a Microsoft shop. The development and operations talent in house are all world-class experts in .NET/C++/C#.  This made the decision process very non-obvious.  Do we choose a hot new platform so we can build it quickly with external resources, only to go through a steep learning curve later when this new work is brought back in house?

This is a head scratcher for me and I am actually not sure what I would do if it was my team.  I think I would lean towards picking the trendy platforms.  I probably would plan on hiring at least one new senior or principal level developer who is highly experienced in the new platform, and retraining those who are able and willing to share custodianship for the new platform.  But it is as much a budgetary and human resources consideration as it is a technical decision.  The best technical decision could be an ill advised business decision in the long run.

What would you do if this was your team?


Twitter Updates


%d bloggers like this: