Marketing Requirements Document (MRD)
Abstract:
This product release, code-named "Babylon-6," addresses three top requirements. In order, they are [1] meeting the emerging market need for teleportation, [2] boosting internal quality and supportability through telepathic diagnostics, and [3] increasing networking price-performance. All three are required for successful release and launch, which is planned for next Wednesday.
In addition, a wide variety of other improvements and extensions have been identified. None of these are defined as gating items for the release, so may be postponed if they threaten timeliness or functionality of the release.
Revision History (example)
V1.0 First draft for comment, 01-Jan-2001
V1.5 Incorporating feature order, 18-Sept-2001
V2.0 Coordinated with feature sizing from Development, 22-Mar-2002
V2.1 Revised based on initial alpha tests (liability concerns from Corporate Legal), 15-Apr-2003
V3.0 Redefined for use only on inanimate objects and cargo due to slight side effects, 20-Jun-2004
V3.1 Updated links and website information, 15-March-2006
Table of Contents
1.0 Strategy and Overview 3
1.1 Goals and Objectives. 3
1.2 Strategic Road Map 3
1.3 Customer Categories (User Profiles) 3
1.4 Competitive Strengths and Weaknesses 4
1.5 External Positioning 4
1.6 Microsoft 4
2.0 Business Model 4
2.1 Value Proposition 4
2.2 Market Segment 5
2.3 Value Chain Structure 5
2.4 Cost Structure 5
2.5 Position within the Value Network 5
2.6 Competitive Strategy 5
3.0 Affected Groups 6
3.1 Development 6
3.2 Marketing 6
3.3 Support 6
3.4 Operations 6
3.5 Sales 6
4.0 Bill of Materials 6
4.1 Transporter Server 7
4.2 Transporter Console/GUI 7
4.3 Sound Generator 7
5.0 Internally Committed Requirements 7
5.1 Elimination of Top 5 High-Priority Bugs 7
5.2 Internal Performance Improvements 7
5.3 Backward Compatibility 7
5.4 Next-Generation Architectural Changes 8
5.5 Platforms and Protocols 8
5.6 End-of-Life for Older Versions 8
5.7 Uptime and Quality of Service. 8
6.0 Externally Committed Requirements 8
6.1 Molecular Transmittal 9
6.2 Voice-Activated Debug Mode 9
6.3 Broad Performance Improvement 9
6.4 Auto-Upgrade Feature 9
6.5 Benchmarks 9
6.6 Metering Support for ASP Model 9
7.0 Highly Desirable Requirements 10
7.1 Status Indicators 10
8.0 Future Requirements 10
8.1 Undo/Redo 10
9.0 Features Not Being Implemented 10
9.1 Random Transformation 10
1.0 Strategy and Overview
1.1 Goals and Objectives
{A short, easily measured objective echoed from top page.}
This product release, code-named "Babylon-6," addresses three top requirements. In order, they are [1] meeting the emerging market need for teleportation, [2] boosting internal quality and supportability through telepathic diagnostics, and [3] increasing networking price-performance. All three are required for successful release and launch, which is planned for next Wednesday.
In addition, a wide variety of other improvements and extensions have been identified. None of these are defined as gating items for the release, so may be postponed if they threaten timeliness or functionality of the release.
1.2 Strategic Road Map
This project is part of the company’s overall plan to penetrate financial and supply chain accounts in North America, where early adopters for futuristic capabilities tend to collect. In addition, it helps us in our core decision support base, which has been waiting for performance improvements to move very large files among planetary systems. Non-Earth customers are a secondary target for the company, and this product.
1.3 Customer Categories (User Profiles or Personas)
{Detailed description of target users and buyers. May require several sets of target descriptions, with as much information about customer environments as can be found. Are users road warriors with Palm Pilots, or help desk staff running system management tools?}
Target customers are expected to fall into the following categories and usage profiles:
1.3.1 Current customer base, looking for performance upgrades and improved diagnostics. Most are currently on support contracts, so do not generate incremental revenue – but are our leading source of references and upgrades. Usage patterns should be similar to current applications, with increasing use of new diagnostic features and on-line downloading of financial indicators.
Most vocal current customer is HP printer logistics division, which needs to ability to make urgent deliveries to remote customers at low cost. Babylon-6 should allow HP Logistics to centralize printer supplies in Roseville CA and Bangalore, reducing real estate costs and in-pipeline inventories elsewhere. See detailed use case attached…
1.3.2 Hi-Tech Mergers & Acquisitions users, who will be most interested in reducing latency of financial updates and pricing. Moving price data through teleportation gives program traders and hedge funds a way to "lead the market" by as much as 5 seconds. For this group, raw transmission speed is the only criterion.
Figure A shows a schematic how our system will fit with pricing data from major exchanges, (NYSE, NASDAQ as delivered through Reuters/TIBCO) and buy-side interfaces with portfolio trading apps.
1.3.3 Plastics Manufacturers, who need dramatically better price-performance to reach production economies. Our previous versions have required too much computing power for this market. A 3.5x improvement in price-performance brings us into the right range for the first time, and ahead of our competitors. In this segment, total system cost and support for very large storage arrays will drive purchasing decisions.
Chart B shows current and future performance (in absolute and price-performance terms) for this segment. If necessary, a market-specific lease option will be created to lower upfront buy-in costs.
1.4 Competitive Strengths and Weaknesses
Our biggest competitor has failed to address key aspects of this market. They have neglected new transport methods in favor of old-style fuel-based mobility. "Babylon-6" will let us tilt the PR playing field in our favor ("old versus new") as well as sell upgrades to older customers no longer on contract. In particular, we should be able to take share away from BigCo based on their clumsy pricing and slow development cycles.
Since we will not yet have filled some holes in our own product line (especially safety testing for transport of people and live cargo), we will de-emphasize this in our materials and use cases. All marketing and advertising will picture transporting of physical (no-living) goods. In addition, Corporate Marketing will provide delivery insurance to cover any losses from mis-directed shipments.
1.5 External Positioning
{A pithy summary of what's new and different enough that press/analysts will listen}
At launch, we will position this with the broad non-technical press as…
and focus technical reviewers/readers on…
Our comparison with existing competitors will focus on…
For existing customers, our top-line message will be…
1.6 Microsoft
This is in potential competition with several long-term Microsoft initiatives, such as "Penfield-Jackson" and "R2D2". Our plan must be either to [a] make this an attractive partnering opportunity for Microsoft, with hopes for free bundling or acquisition, or [b] position it as complementary to Microsoft’s incomplete lower-level offering, which we assume will be bundled at no charge in all of the following products and suites: Office2006, MoonExplorer, and "USBeam".
Any discussion with press or analysts will include a designated PR / Product Marketing representative to cover Microsoft questions.
2.0 Business Model
An explicit description of this product (service) and "how it makes money" is important to careful planning . While the business model may change with competitive shifts or learning during the development cycle, assumptions about marketplaces and pricing will drive many decisions and define how we win against existing offerings.
2.1 Value Proposition
Clear description of the value created for users by the product/service, including reasons why current offerings are insufficient.
Example: database stored procedures (a.k.a. triggers) allow program trading of securities driven by real-time market price data. Pre-existing solutions required manual intervention or batch price scans, which were too slow to catch real-time market moves. This technology created a new class of traders able to arbitrage tiny market inefficiencies, and made millions for early Wall Street adopters.
2.2 Market Segment
Who are the users (IT, line of business, roaming execs, home surfers…)? What are the details of the application?
Example: a global Internet dial-up service is targeted at roaming business users with Windows laptops who cross national boundaries. They dial in for email and corporate IP applications (on average) twice per business day and infrequently on weekends. They are non-technical, so cannot be counted on to configure any local settings or understand the subtleties of local telephone services.
2.3 Value Chain Structure
How will this be distributed? What are necessary complementary products? What prerequisites will customers require (and that can be used as marketing screens)?
Example: a real-time alerting system for corporate back-office applications requires deployed, working corporate applications (e.g. ERP or finance) and browsers installed on all end user systems. It is a complement to these large apps, adding value to triggering or error status features, since end users often fail to see urgent alerts. As a stand-alone offering, it lacks high-value content. Can Marketing create a simple targeting screen for early location/qualification of prospects?
2.4 Cost Structure
Is this a service or a product? Are costs driven by one-time R&D or ongoing support and provisioning? What is the profit potential given the customer proposition and value chain?
Example: a transaction-based service has high fixed (start-up) costs and low per-transaction costs. A 24*7*365 support team is expensive to maintain, but can manage a large number of cases without expanding. Company needs to get a minimum revenue per month (day, year) to cover support costs and amortize R&D, but needs relatively little per additional transaction to generate profitability. Subscription model and per-transaction fees are possible pricing solutions.
2.5 Position within the Value Network
How does the company link with suppliers and customers? Which are likely complementors and competitors? Who would lead in a teamed sales model?
Example: Fault-tolerant systems platforms are required for 911 applications as well as cash machine networks. In both cases, the customer requires a custom software solution, which is chosen before the hardware/OS combination. The systems provider must team with top vertical app developers and win their attention/loyalty versus alternate platform providers. Natural channels are OEM through application vendors; VAR through system integrators; in-house application development teams; investment or acquisition of leading app providers.
2.6 Competitive Strategy
How will we gain advantage over competitors? What unique resources do they lack, or conflicts have they created, that keep them from using the same strategy? Look for specific "hard" items, rather than generic answers (e.g. focus, smarter team, reputation).
3.0 Affected Groups
3.1 Development
Development will need to build an overall plan, and execute against that plan. Current target date for first beta release is April 2007, and general availability in August 2007. Unless explicitly signed off, all listed features and functions will be included. Where trade-offs are made, Product Marketing will be included in the decision process.
QA will be done by our testing group in… This is targeted as part of our broader release of version 5.0 scheduled for…
3.2 Marketing & Sales
Product management will be done by… External PR and announcement planning will start in Nov-2006 and be headed by… Training materials and vertical market white papers will be the responsibility of… Leads and new prospects will be identified by a combination of direct mail, opt-in email and seminars starting in…
SALES: Key accounts known to want this product are… Formal sales training is planned for… Field technical resources will be trained in advance of customer betas. Current beta dates and prospects are… Identification of target accounts among the installed based will be done by…
3.3 Support
This product addresses the following known weaknesses in our current offering, as identified by Support… We will designate a "tiger team" to handle beta and early production calls from customers from our Support group in… Sign-off on customer and internal training materials will be done by… In addition, Support will recruit untrained customers and prospects to do user testing of the beta product. Users will attempt to install and use the product without manuals or install guides, and will score their experience. If 70% of these testers are unable to perform a minimal set of product functions {list}, Product Management and Support will do a full review of UI and functional designs.
3.4 Operations
Operations must …
Quality of service metrics for this product are…
Test installations and Operations acceptance testing will be done by…
3.5 Sales
Starting in Jan-2007, we will begin looking for beta customers among the existing installed base. This will be led by Sales, specifically Meredith Greenfield (Omaha) and Patty O’Furn (Dublin)…
Presales SEs will get two rounds of product training: initial concepts and selling strategies. Sales Training will be responsible for coordinating these events and turning standard marketing deliverables into Sales formats…
Marketing will launch a contest and campaign during the first three months of availability, with prizes for all Reps who close more than one account…
3.6 Legal
For some products (e.g. this teleportation product), developers will need to worry about liability and failure issues – and include a legal review of the product or claims. Consider the consequences of a network outage on hospital systems, or a security breach of law enforcement databases. For teleportation, are there disclosures and warnings that would minimize lawsuits when an occasional user arrives as a puddle of quivering protoplasm?
4.0 Bill of Materials
This section identifies all of the customer-visible product deliverables to be produced, as well as customer site requirements and dependencies. From this list, a development schedule can be created to complete everything needed "in the box" for successful customer installations and deployments. Once this BOM is matched to a product architecture, all pieces are required – therefore no priority is implied by this section’s numbering scheme.
4.1 Transporter Server
This server software runs on a conventional App Server provided by BEA (WebLogic) or IBM (WebSphere). It controls all transporter functions and continuously checks for errors.
4.2 Transporter Console/GUI
The console manages the Transporter Server and provides its user interface. In addition to physical controls, the Console can be managed via voice commands and unobtrusive ASL (American Sign Language) hand gestures.
4.3 Sound Generator
Every cool device needs its own set of special sounds to indicate proper operation. This subsystem lets engineers choose the sound palates most to their liking, and coordinates the sound generator units (SGUs).
4.4 Demographic Upsell Module (DUM)
The DUM asks each teleportation user to provide some demographic information before being transported. This is useful for contacting next-of-kin after a system failure as well as offering additional products (life insurance, destination-appropriate clothing) and adding to Marketing’s database of user profiles. Legal has asked us to include a disclaimer that demographics are not required, and do not have any effect on Quality of Service.
5.0 Internally Committed Requirements
Within this section, each item is ranked, with 3.1 taking higher priority than 3.2, etc. Product owners and development must know which features are most important. In general, this section contains features or improvements that are invisible to customers, or which will not be announced.
5.1 Elimination of Top 5 High-Priority Bugs
Technical Support and Product Management have compiled a list of our most serious software defects, as follows. All of these must be fixed and tested prior to release. As of this writing, they include:
• Buffer over-write on messages > 28.4 TB
• Memory leak causing required reboot of core service every 88 hours
• Truncated header data on Type II EDI lookups
• Removal of end user option to turn off software updates
• Misreading of ICMP packets as AppleTalk printer queue requests
5.2 Internal Performance Improvements
Two bottlenecks have been identified that are generally not yet visible to customers: retrieval of real-time database records during backup cycles, and simultaneous receipt of multiple items by a single transmitter. Both will start to show up in customer testing (or live production use) as traffic builds beyond 65 GB/hour. Development must tune/redesign the MMG and T6 modules, and QA must verify that we can score more than 88 on the TCP-X benchmark.
In addition, we will require improvement of at least 20% on each of the following metrics…
We will also need more complete analysis charting of the key performance variables that customers keep demanding. This includes the improved performance from additional server memory up to 512GB and support for larger "chunking" hardware to handle extra-long organic molecules such as DNA.
5.3 Backward Compatibility
This version of our product will work with previous versions starting with v2.0 and including our most recent release (4.4B). It must allow a mixed use model, with all versions running simultaneously on separate machines, since forcing an instantaneous upgrade is not yet possible. With the following exceptions, no functions or capabilities will be removed in this version:
• Backup/restore will be limited to formats from versions 4.0 and later. Older backups can be retrieved using a pre-existing copy of the software.
• The "audio only" communications mode will be discontinued.
Customers will be notified 9 months in advance (in writing and from their sales teams) of these changes.
5.4 Next-Generation Architectural Changes
This release will include changes to internal data structures and management mechanisms that will not be complete or visible until a later release…
5.5 Platforms and Protocols
Server-side software will run on Red Hat Enterprise LINUX v7.2 and later, Windows Vista Server 2.5+, and Solaris 10. No special client-side software will be required other than browser support (minimal set of HTML and AJAX supported by both MSIE 6.1+ and Firefox 2.0+). Client-side browser testing will be done on Win2k, WinXP, MacX, LINUX 7.0+ and PalmOS. Communications will be assumed as HTTP(S) or FTP over standard TCP/IP unless otherwise stated.
5.6 End-of-Life for Older Versions
Starting 3 months after launch, we will announce end-of-life (EOL) and end-of-support (EOS) for previous versions running on a variety of obsolete platforms. These include HP-UX, all IBM OS platforms other than LINUX, ULTRIX, DEC OSF/1, SGI IRIX, back versions of Ingres and Informix databases, and networking support for IPX and AppleTalk. Customers will be given from upgrades to any supported platform. Our EOL program outline will be:
• Notify all customers in writing of impending EOL/EOS three months after this launch
• Include offer of free upgrade/ migration to any currently supported platform within 12 months of announcement
• Special "SWAT team" created for professional services opportunities with customer migrations
• No additional patches or fixes to be made 6 months after announcement date
• No ongoing support or technical assistance 12 months after announcement date
5.7 Uptime and Quality of Service
Customers are assumed to accept at least 22 minutes of downtime per month for upgrades, database backup, and hardware preventive maintenance. All configuration and management functions must be performed while applications are running, so cannot require any shut-downs, off-line periods, or restarts. This translates to 99.95% uptime. Operations will monitor and report on all known customer downed systems, collect statistics, and calculate actual field uptime. In addition, monitoring software within the application… Third party test tools will include… Once we have achieved our target uptime, we will begin reporting this monthly to customers as an aggregate result (averaged over all customers and all systems). We will make our measurement tools available to customers who want to track their own uptime…
6.0 Externally Committed Requirements
Within this section, each item is ranked, with 4.1 taking higher priority than 4.2, etc. External announcements and customer communications will follow this list, since they are ranked in importance. If the first 4 items are not completed, we will delay launch until they are finished and fully tested.
6.1 Molecular Transmittal
AKA teleportation, this is the ability to move matter to remote devices without traversing the intermediate space. Customers are eager to get this feature, and the competition is years behind in developing it. Several major customers are waiting for this, including …
This is a major new capability and will set us apart from the competition by allowing customers to…
6.2 Voice-Activated Debug Mode
Since users often have their hands full when problems develop, this new feature allows them to ask "what if" and "what’s wrong" directly – instead of touching a keyboard. Filtering has been included, which deletes inappropriate words before logging and translating them.
Note to QA: extensive testing must be performed on sound-alike words. For instance, customers in the supply chain may often use "ship" or "truck" so should not have these blocked or deleted.
6.3 Broad Performance Improvement
We must show general performance improvement of at least 35%, as measured with our internal ZING2 test suite. This reflects actual customer applications. We will also use standard industry benchmarks (below), which must show at least 30% improvement.
If our work to overcome internal bottlenecks (above, section 3) contributes to this, then we have a double win. If not, we still require that customers running normal application loads or benchmarks see marked improvement. Therefore, a full set of CPU usage and wait time data will be required from our PerfLab – including identification of the top 6 to 10 CPU "hogs" and network latency areas.
6.4 Auto-Upgrade Feature
Customers continue to have difficulty accepting, scheduling or applying software updates (patches, interim releases, and major upgrades). This release will include an "auto-update" feature that is enabled by default, but can be turned off by the customer or by us. In addition, it must allow for selective upgrades by version and customer ID.
If accepted by customers, we expect to discontinue our distribution of physical media in Jan-2008, and begin increasing support charges for versions more than one year old. Customer Support expects this to allow promotion/redeployment of more than 10% of their staff, and is an important part of their plan to reduce case turn-around times by 35% during FY2008.
6.5 Benchmarks
We will run the following performance tests internally, with a plan to release benchmarks beating the competition… Third party test labs that will re-run or verify our results are… Publications that promote these benchmarks include…
6.6 Metering Support for ASP Model
Marketing will require a pricing mechanism for ASPs (application service providers) who will offer teleportation "per trip" rather than on a full license basis. Product must support a method for counting and billing for each use. Ideally, this will include packet counts, so that larger items can be billed at higher rates than smaller ones.
7.0 Highly Desirable Requirements
This section shows items that may be included in this release, but are not committed yet. It is intended to reduce questions about "that thing we asked for, but isn’t included on your list." In general, since lists get shorter during development, few of these items are expected to fit in the current release.
7.1 Status Indicators
While not required, this will dramatically reduce calls to Technical Support. (It may also reduce lawsuits.) System should show status of all transfers in progress, as well as statistics and details on completed and queued transfers. Data must include date/time, destination, origin, size, weight, and delivery options.
Red "alert" signals must identify if any item has failed to be received intact, or if queued items have been flushed from buffers.
8.0 Future Requirements
This section shows items that may be included in later releases, but are not committed in this release. It is intended to reduce questions about "that thing we asked for, but isn’t included on your list."
8.1 Undo/Redo
This has been requested by many customers, but is not included in this release. Some architectural work has been slipped into the main code line for completion in later releases. For now, customers who send something do not have the option to "change their minds" or later destination coordinates.
9.0 Features Not Being Implemented
Some requests are specifically excluded or denied. Showing them here is an excellent way to move conversations from "when?" to "why not?" Most requests that do not come from a major customer or support critical strategic objectives end up here.
9.1 Random Transformation
Two vocal customers have made repeated requests for items to be transformed – at random – during teleportation. This is a fundamentally bad feature, since it could be turned on accidentally or by hackers. Please be clear and unambiguous with customers that this is not a feature we will ever implement, and that enhancement submissions will be closed with the "Not Under Development" label.
Impressum
Tag der Veröffentlichung: 17.03.2010
Alle Rechte vorbehalten