Marketing Requirements Document (MRD by syed sajid (ebook reader computer TXT) 📕

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