r10 - 26 Jun 2006 - 16:49:18 - MimiYinYou are here: OSAF >  Projects Web  >  ContributorNotes > KatieParlanteNotes > ProductPlanProcess

Product Plan Process

We're taking an iterative approach to working on our product strategy. One piece of the strategy is the business model. Another piece is the product/service definition. Market research may inform both. In this exercise we are starting with the product/service definition from a user-driven perspective, knowing that ultimately it needs to be informed by the business model.

Elements of product strategy

  • Business plan
  • Product plan
  • Market research

Goal of product plan

  • Shared image of success, shared crisp goal to help us focus
  • Help make hard decisions, answer questions

A successful product plan will...

  • Enable us to defend how/why our products and services will create value for users.
  • Help us find a path to sustainability in the next 2 years
  • Answer these questions (among others):
    • What is our email strategy?
    • Who are our target users?
    • What is the Scooby 1.0 plan?
    • Should Cosmo be a reference CALDAV implementation? Should Cosmo support Chandler-Scooby semantic sharing?
    • How large does the repository need to scale for performance?
  • Propose an answer to the Million $ Question: What combination of things that we have done (and/or can do relatively quickly/easily) are unique and valuable?

A product plan looks like...

  • Defines a suite of 1.0 products and services. (Chandler, Scooby, Cosmo)
  • Defines target users for these products and services.
  • Defines representative usage scenarios for the suite of products and services.
  • Defines a roadmap for all 1.0 products and services: tenets, workflows, features.

Constraints and assets

  • 1.0 products and services must be ready in 2 years. Plan for 12-18 months.
  • Available resources (staff)
  • Working code
  • Existing designs
  • Existing architecture decisions

#Vision Elements of our vision at OSAF

  • Small workgroup collaboration (find innovative ways to solve problems that prevent people from using existing tools)
    • Esther managing Mitch's calendar
    • OSAF sharing an Office calendar
    • PPD team sharing a Team collection
    • Ted and Julie sharing a Home collection
    • Collaborative management of the Design list
  • Standards-based interoperability
    • CalDAV cients on the Desktop and Web
    • Providing a CalDAV server for other CalDAV clients
    • iMIP invitations
    • Sharing with other CalDAV clients
  • Interoperability with existing clients
    • Drag and drop emails, documents, tasks and events into Chandler from other apps
    • Receive Chandler attachments in existing email and IM clients and d-click to add item to Chandler
  • GTD as inspiration for managing too much information
    • Triage workflows
    • Iterative approach to task management
  • Extensible/customizable PIM
    • Making it easy for Contributors to help: SPAM filters, Spell-check, HTML editing, Localization
    • New views (ie. Mindmap, Timeline view, Outline view)
    • Documents parcel
    • Project management parcel
    • CRM parcel
    • Research parcel
    • Flickr/Delicious parcel
  • Data hub, semantic web
    • Allowing users to define their own Domain models: New Kinds, Sub-Kinds, Attributes and Attribute Types
    • User-defined relationships between items: Linking and Threading
    • Attribute-based item browser
  • Agenda 2.0: flexible organizational system, user controlled semantics
    • User-defined attributes
    • User-defined relationships between items: Linking and Threading
    • Attribute-based item browser
    • Smart parsing of text commands for creating new items, assigning dates and times and other metadata
  • Calendars without IT support
  • Cross platform PIM
  • Open source contributors collaborating with us to get more work done
  • Open source contributors collaborating with us to create a more innovative project
  • Web 2.0:
    • Linking to map services for event locations
    • Hooking into social networking services
    • Subscribing to RSS feeds, Web Services (ie. Amazon wish lists)
    • Mashups
  • Access to data from multiple avenues (rich, hip and thin)

Decisions we've already made

Although in theory these are consistent with the overall vision, OSAF has decided not to fund certain efforts:

  • We're supporting shared calendars (and other information) through a sharing service, not P2P sharing
  • We're not supporting a hypercard-like end user scriptable application
  • We're not writing a generic application building framework

Proposed Process

At each step, we'd like to get feedback from the ops team, the core team, and the community at large.

  • (1) Prioritize the elements of the "vision". Assumption: we have too many competing drivers here, and arguing about these causes tension and lack of focus. If we can make a decision about priorities, it will help make the next set of decisions easier.
    • We could get people on the design list to prioritize the list as an exercise (non-binding)
    • Each member of the ops team could prioritize the list as an exercise
  • (2) PPD team proposes user problem, target user and usage scenarios
  • (3) PPD team proposes product roadmap (aka "stickie plan")
    • 1.0 tenets
    • list of workflows
    • list of features needed to support workflows
    • phasing proposal for feature implementation

Questions for the ops team

  • How can we best get input from the core team and the community at large?
    • What exercises do we run?
    • What questions do we ask to elicit useful input?
  • Do we have the right "vision" list? Anything you'd like to add?
  • Should we add to the "decisions"? Something about agents?
  • Stakeholders?

Assumption: The PPD team should draft product plan proposals, instead of trying to collectively compose proposals.

Terminology

  • User problem What problem does the suite of products and services solve? (e.g. a small group of people who can't afford an enterprise solution want to coordinate work with each other)
  • Target user Who will use this suite of products and services? (e.g. university it departments)
  • Usage pattern A pattern of usage defined around a common verb: Record, Process, Document, Archive. A set of Usage Scenarios with roughly the same workflow morphology.
  • Usage scenario Common user need that falls into the space defined by the user problem, possibly using mulitple products/services (e.g. 3 people collaboratively editing a document)
  • Use case Specific user task (e.g. keep track of status on the collaboratively edited document)
  • Workflow Steps user takes to accomplish a specific user task (e.g. 1. double click to create new event 2. type event title)
  • Feature Piece of functionality that supports workflows (e.g. email address auto-complete)


Philippe's Comments

A successful product plan will...

  • I don't think that the question "what is our email strategy?" needs to be answered up front. This becomes a question if the user workflow we have requires email. So we need to answer the target user and target customer question first.
  • We need to realize that our target user and target customer might not be the same person. i.e. the target user will certainly be some kind of individual clicking on Chandler's or Scooby's buttons to get something done. The target customer might be a service provider or another kind of bundling mid tier entity packaging the service to end users. Identifying this target customer is key in shaping the product strategy. e.g.: if we decide to target mid tier bundlers to get licensing revenues, the "platform" aspect (API, doc, standard) become front and center in the product design; if we target end users, UI fit and finish become 1st prio issues.
  • Million $ Question: our unique stuff
    • Non centralized sharing (a client can share from and with several Cosmo/CalDAV servers)
    • Corollary : collaboration across groups is possible (decentralized collaboration)
    • High level of customization through parcels, way beyond skinning, even custom data (relevant to address vertical markets)
    • Synthetic approach to personal data (no silos, not even limited to PIM data)
    • Truly platform agnostic (with a big hole on Mobile though...)
    • Open Source nature of our solution

Elements of our vision at OSAF

All important but here's my priority order in term of how this shape the product strategy:
  • Small workgroup collaboration (find innovative ways to solve problems that prevent people from using existing tools)
  • Calendars without IT support
  • Agenda 2.0: flexible organizational system, user controlled semantics
  • Standards-based interoperability
  • Interoperability with existing clients
  • Extensible/customizable pim
  • Cross platform pim
  • Access to data from multiple avenues (rich, hip and thin)
  • Open source contributors collaborating with us to get more work done
  • Open source contributors participating in the design process to create a more innovative project
  • Web 2.0: social networking, mashups, etc.
  • GTD as inspiration for managing too much information
  • Data hub, semantic web

Questions for the ops team

  • We need to get more end users so we let the product design being prioritized by real users. We're getting there, we need to get better at it.
  • Vision : I feel we could add something about inter group collaboration, like a "web of PIMs" (non centralized servers, links to any others)
  • Vision : we're missing a Mobile story, that's our biggest solution coverage issue, I'd say more important than email
Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r10 < r9 < r8 < r7 < r6 | More topic actions
 
Open Source Applications Foundation
Except where otherwise noted, this site and its content are licensed by OSAF under an Creative Commons License, Attribution Only 3.0.
See list of page contributors for attributions.