Software Products: Chapter 1 Study
Guide
Based on Engineering Software Products
1 Introduction to Software Products
This section sets the stage by defining what software products are and how they differ from the
”traditional” software engineering approach.
1.1 1. What is a Software Product?
Definition
Software products are generic software systems sold to governments, businesses, and
consumers.
• Scope: They range from massive business systems (millions of lines of code) to simple
mobile apps.
• Examples: Productivity tools (Word), business functions (accounting), games, or personal
apps.
1.2 2. The Shift: Project-based vs. Product-based Engineering
The most important concept in the introduction is understanding the difference between cus-
tom (project-based) development and generic (product-based) development.
A. Project-Based Software Engineering (The Old Way)
• Origin: Norm in the 1970s for specific clients (e.g., banks, military).
• Process:
1. Specific Customer: An external client has a specific problem.
2. Requirements First: The client defines exactly what they want in a contract/require-
ments document.
3. Development: The software is built to satisfy those specific requirements.
• Key Characteristic: The customer pays for development and controls changes.
B. Product-Based Software Engineering (The New Way)
• Origin: Businesses realized they didn’t need custom software; they could use generic so-
lutions for common problems.
• Process:
1. No Specific Customer: There is no external client defining requirements.
1
2. Opportunity First: The developer identifies a market ”opportunity” or idea.
3. Feature Selection: The developer decides what features to include to appeal to buy-
ers.
• Key Characteristic: The developer controls the product roadmap, updates, and when to
withdraw the product.
C. Summary of Differences (Important for Exam)
Feature Project-Based (Custom) Product-Based (Generic)
Driver A specific customer problem A market opportunity identified by
developer
Requirements Defined by the customer Decided by the developer
Who pays? The client funds development Development costs spread over
many users
Changes Customer requests and pays for Developer decides when to update
changes
Speed Focus on ”getting it right” Focus on ”time to market” (rapid de-
livery)
1.3 3. Related Concepts: Product Lines vs. Platforms
It is crucial to distinguish these terms from standard products.
Software Product Lines: A set of products that share a common core but are adapted for spe-
cific customers (e.g., emergency service software adapted for different police forces).
Platforms: A product that acts as a foundation for other developers to build upon (e.g., Face-
book allows others to build apps on top of it).
1.4 4. Execution Models
How does the software actually run?
1. Stand-alone: The software runs entirely on the user’s computer (e.g., traditional installa-
tion from a disk).
2. Hybrid: Some functionality is local (on your device), but it relies on remote servers for data
or heavy processing (e.g., many mobile apps).
3. Software as a Service (SaaS): The software is accessed via a browser/app, but all execution
and data storage happen on the vendor’s servers.
2
2 Section 1.1: The Product Vision
The ”Product Vision” is the starting point of any product. It prevents you from getting lost in
technical details by defining what you are building and why.
2.1 1. What is a Product Vision?
Vision Definition
A simple, succinct statement defining the essence of the product.
Purpose: It acts as a ”north star.” As new features are proposed, you check them against the
vision to see if they fit.
2.2 2. The Three Fundamental Questions
A vision must answer these three questions:
• WHAT is the product? (And how is it different from competitors?)
• WHO is it for? (Target users/customers)
• WHY should they buy it? (Commercial viability)
2.3 3. The Vision Template (Geoffrey Moore)
The text recommends a specific template. Memorize the bolded keywords.
Moore’s Template
• FOR (target customer)
• WHO (statement of the need/opportunity)
• The (PRODUCT NAME) is a (product category)
• THAT (key benefit/reason to buy)
• UNLIKE (primary competitor)
• OUR PRODUCT (primary differentiation)
Example: FOR mid-sized companies WHO need sales tracking, THE CRM-Innovator is a
web service THAT improves relationships... UNLIKE package software, OUR PRODUCT is
low cost.
2.4 4. Where does the Vision come from?
It is rarely a sudden ”Eureka!” moment. It comes from refining ideas using four information
sources:
• Domain Experience: You work in an industry (e.g., marketing) and see a need for better
tools.
• Product Experience: You use existing software (e.g., Word) and realize you could build
something simpler or better.
3
• Customer Experience: You talk to potential customers to understand their struggles and
constraints.
• Prototyping: You build a quick experimental version (”play around”) to understand what
is possible.
3 Section 1.2: Software Product Management
This section is all about the people who steer the ship: Product Managers (PMs). Product
management is a business activity focused on the software products a company sells.
3.1 The Role of the Product Manager (PM)
PMs are the bridge between the development team, the business, and the customers. The PM
ensures the team builds things that deliver real value.
PMs must balance three main interdependent concerns:
1. Business Needs: Making sure the software meets the goals of the company/customers,
and planning release schedules.
2. Technology Constraints: Making developers aware of tech issues that affect the sched-
ule, cost, or functionality.
3. Customer Experience: Understanding how users work, their capabilities, and involving
them in testing.
3.2 7 Technical Interactions of a PM
While PMs do business tasks, the chapter focuses on how they interact with the development
team.
Key PM Responsibilities
1. Product Vision Management: PMs take the lead in creating the vision (with the
team). They must protect the product from ”vision drift,” where the focus gets too
broad.
2. Product Roadmap Development: A plan setting out milestones, release dates, and
key features. Timing is crucial (e.g., financial year ends).
3. User Story and Scenario Development: Writing natural language descriptions of
what users want to do to help the team decide how features should work.
4. Product Backlog Management: The dynamic ”to-do list.” The PM prioritizes this list
and decides if new suggestions jump the queue.
5. Acceptance Testing: Developing tests reflecting how customers will actually use
the product to ensure it meets roadmap goals.
6. Customer Testing: Taking the release to real customers for feedback on usability
and business fit.
7. User Interface (UI) Design: The PM acts as a ”surrogate user,” ensuring UI features
aren’t overly complex.
4
4 Section 1.3: Product Prototyping
A product vision is great, but users and investors need to see something working. Product
prototyping is building an early version to test ideas and prove market potential.
4.1 Why Build a Prototype?
• Demonstration: Investors (VCs) demand to see it. Helps potential users provide feedback.
• Testing Technology: Tests architecture. You might find the initial design can’t handle the
load.
• Speed: The goal is to get a demonstrable system running in four to six weeks.
4.2 The Two Stages of Prototyping
1. Feasibility Demonstration: An executable system just to see if core ideas work and are
better than competitors.
2. Customer Demonstration: Extending that initial prototype with specific features for the
customer, based on user studies.
4.3 The Golden Rule of Prototypes
WARNING: Throw Them Away!
To build a prototype quickly, you must cut corners—ignoring reliability, security, and per-
formance. Because of these compromises, if your software has external users, you must
treat the prototype as a ”throw-away” system.
If you try to evolve it into the final product, the messy code makes it increasingly difficult
to add new features or apply security.
Note: You should still use automated testing and code management even for prototypes!