SECTION 01 / 3

PART A | SOFTWARE ORGANIZATIONS

5 min read
On this page 12 headings

1. The real purpose of a software company

A software company does not exist only to produce code or to launch an application. Its purpose is to provide value to people who might use the software. The software is a means of achieving that purpose.

A technically impressive product that nobody needs or uses does not achieve this goal. Teams must therefore understand users, identify their problems, and check whether the proposed software helps them.

Remember | Always ask: “Whose problem does this solve, and how?”

Illustration 01 • Value matters more than simply building features.
Illustration 01 • Value matters more than simply building features.
Open image ↗
Value matters more than simply building features.

2. Software development is a team effort

Software engineering involves more than the development lifecycle. It also requires communication and coordination among people who study the market, plan the product, design interactions, write code, sell the product, and support its users.

These roles depend on each other. A decision made by one group can change the work of another group. This is why communication is a professional engineering skill, not an optional extra.

Illustration 02 • Different roles contribute to one useful product.
Illustration 02 • Different roles contribute to one useful product.
Open image ↗
Different roles contribute to one useful product.

3. Marketing: discover needs and opportunities

The marketing team studies opportunities in the market: who the potential users are, what problems they face, and what kinds of solutions may be useful. Market research helps the company decide where it can provide value.

Marketing also promotes the company and communicates its products and services to an appropriate audience. It should understand the product well enough to communicate its real capabilities.

Illustration 03 • Marketing explores user needs and potential markets.
Illustration 03 • Marketing explores user needs and potential markets.
Open image ↗
Marketing explores user needs and potential markets.

4. Product manager: balance three needs

The product manager works at the intersection of business, technology, and user experience. Business asks whether the product supports company goals and return on investment. Technology asks what is feasible, what systems are involved, and how much effort changes require. User experience asks whether people can use the product successfully.

These needs can conflict. The product manager works with marketing, sales, designers, and engineers to make trade-offs. A product manager need not be the person writing code, but should understand enough technology to make informed decisions.

Remember | Product manager ≠ project manager. Product management balances what value to build; project management organizes delivery.

A useful trade-off — Imagine users want a sophisticated dashboard, but it would delay the release. The product manager brings together user value, development effort, and business priorities. The answer is not automatically “build everything” or “reject everything.”

Illustration 04 • Product managers balance business, technology, and user experience.
Illustration 04 • Product managers balance business, technology, and user experience.
Open image ↗
Product managers balance business, technology, and user experience.

5. Designers: turn requirements into usable solutions

Designers focus on how users interact with the system and how requirements become practical solutions. They speak with users, create prototypes, collect feedback, and revise designs.

Design is not simply choosing attractive colours. It includes making workflows understandable, removing unnecessary effort, and ensuring the intended functionality is accessible.

Illustration 05 • Talk to users, prototype, and revise.
Illustration 05 • Talk to users, prototype, and revise.
Open image ↗
Talk to users, prototype, and revise.

6. Software engineers: implement and collaborate

Software engineers work with others to implement requirements through code. Software engineers don't get to decide what product is made or what problems it solves (most of the time).

In startups and small teams, roles are combined: a software engineer may also contribute to product decisions and design.

Illustration 06 • Requirements and designs become working features.
Illustration 06 • Requirements and designs become working features.
Open image ↗
Requirements and designs become working features.

7. Engineering and project management

Engineering managers (also known as project managers) transmit information between higher and lower parts of a large organization: organizing and prioritizing work, coordinating between teams, and resolving interpersonal conflict between engineers.

Illustration 07 • Coordination makes a complex project manageable.
Illustration 07 • Coordination makes a complex project manageable.
Open image ↗
Coordination makes a complex project manageable.

8. Sales: reach customers and return feedback

The sales team works to bring the product to customers identified through market activity. Sales also learns what prospective and existing customers want.

This feedback matters to the next product cycle. Requests, objections, and problems heard by sales can be passed to marketing, product management, design, and engineering. However, the sales team should not promise technically impossible or excessively costly features without consulting development.

Illustration 08 • Sales connects customers with the product team.
Illustration 08 • Sales connects customers with the product team.
Open image ↗
Sales connects customers with the product team.

9. Customer support and escalation

Customer support helps people who get stuck using the product. Help can be provided through documentation, FAQs, chat, email, or telephone.

Level-1 support typically addresses common questions and known problems. A difficult bug or unusual problem can be escalated to Level-2 or another specialist. Support also reports recurring defects and usability problems back to the product and engineering teams.

Illustration 09 • Simple questions are handled first; complex issues are escalated.
Illustration 09 • Simple questions are handled first; complex issues are escalated.
Open image ↗
Simple questions are handled first; complex issues are escalated.

10. Data scientists: turn data into insights

Data scientists analyse information generated by users and different company teams. Their findings can reveal sales patterns, app-usage trends, and areas for improvement.

These insights help marketing, engineers, and product teams make better-informed choices about future releases or business direction.

Illustration 10 • Data can guide product and business decisions.
Illustration 10 • Data can guide product and business decisions.
Open image ↗
Data can guide product and business decisions.

11. Ethics and policy specialists

Software products often involve data, permissions, licensing, and risks of misuse. Ethics and policy specialists bring expertise from fields such as law, policy, and social sciences.

They help shape terms of service, software licences, privacy policies, and decisions about responsible use. Their role is particularly important for systems handling large amounts of data or having significant potential for misuse.

Illustration 11 • Privacy, licensing, and responsible use matter.
Illustration 11 • Privacy, licensing, and responsible use matter.
Open image ↗
Privacy, licensing, and responsible use matter.

12. Many roles, one product

No single department can deliver customer value in isolation. Marketing discovers needs; product management balances priorities; design plans the interaction; engineering builds; sales reaches customers; support resolves problems; data analysis identifies patterns; and policy expertise helps address responsible use.

The central lesson of the first lecture is to consider other perspectives and collaborate rather than focusing only on your own assigned work.

Remember | Think of the software product as a shared responsibility, not a collection of isolated tasks.

Illustration 12 • Feedback and decisions connect all teams.
Illustration 12 • Feedback and decisions connect all teams.
Open image ↗
Feedback and decisions connect all teams.
YOUR STUDY PROGRESS

Finished this section? Save your progress.

Back to top ↑