Topics in Software Product Management

This specialization will cover four core topics in software product management:

• Process
• Requirements
• Planning
• Monitoring

Process

A process organizes the work of people into distinct high-level phases or stagrs to develop a software product. Example phases are:

• Specification
• Design and Implementation
• Verification and Validation

Specification activities discover and define what the software is expected to do.

Design and implementation activities structure and construct the software solution.

Verification and validation activities test for potential defects and review whether their product meets the client's needs.

 

Process is necessary to organize our development and make sure that you are completing things in a logical order. They also ensure that steps are not missed or overlooked. Software development is pretty dauning when you don't know where to begin. Processes also provide clarity as to where you should start yout project.

 

Ad Hoc developement occurs in the absense of a process structure and describes a development scenario where work is done reactively to inputs such as developer ideas. or client demands. Ad hoc development can be inefficient with developers potentially wasting time on illconceived features.

 

Requirements

Good development processes help you to develop a product effiently, but that's only half the story. Every project needs requirements to define the product to be built. How you well define those requirements often dictate whether the project is a success. Therefore, it's important to get requirements right.

 

In softare, requirements are a set of a specific descriptions to help capture your client's needs. Requirements can be mapped to features of the software product. When combined, processes and requirements are the backbone of any successful software project.

 

Clear requirements are important. Ambiguous requirements can create confusion among the development team and with the client. Avoiding confusion is an important part of the software product manager's role. There are techniques to properly elicit and express requirements. By spending the time to refine requirements, you can also detect potential errors in yout product before it's even built. By calrifying ideas, development becomes focused and efficient.

 

Planning

According to Alan Lakein, "Planning is bringing the future into the present so that you can do something about it now." Planning involves organizing tasks and schedules to algn software development activities with requirements, in order to make progress through the phases of the development process. Creating tasks and schedules requires indentifying who should do the work, and estimating how long that work will take. Planning includes:

• Breaking down work into tasks
• Estimating time for tasks
• Assigning work
• Risk management
• Contingency plans

Planning is not just for the beginning of the project. In software development, planning is something that occurs constantly throughout the project. Software is always evolving. Your plans have to be flexible! When you have a process to review your plan, your project becomes more agile. Meaning, you can easily adapt to change.

Time Estimation

Poorly written requirements make accurate time estimates difficult. The more specific the requirements are, the clearer it is to estimate how long the work will take to complete!

 

Assigning Work

The developers and the software product manager determine the time estimates for tasks in software development. The developers know best how long it takes them to develop features, but as a software product manager, you also have a sense for timelines based on your own experience.

 

Risk Management

If you can idenify risks and do something in the present to mitigate them, then your project will have a higher chance of success.

 

Risk management entails developing contingency plans to address risk. What are some examples of things that could go wrong?

• What if a developer gets sick?
• What if someone quits?
• What if your client contact changes?
• What if your technology crashes?

Through risk planning or risk management you can anticipate problems that may occur and formulate contingency plans in the event the risks become real.

 

Monitoring

As a software product manager, you can’t establish the process, requirements, and plans, and then step back to watch the development team do their thing. When things change in the project (and they will change), it’s important to have an idea of what’s going on in the project, so that you can deal with these changes as effectively as possible. Monitoring also helps to make sure you’re on track to meet your goals. If you’re not, monitoring also helps you to find out why, and what you can do to fix it. In essence, monitoring your progress helps you to stay afloat over the lifetime of the project.

 

If the client asks for more features, a manager effectively monitoring the project can easily gauge whether their team has available resources, allowing them to adapt to changes within the project for a much higher likelihood of success. This moves you from being a reactive software product manager to a proactive software product manager.

 

Transparency is another aspect of monitoring. Transparency means that everyone on the team knows the status of the project, not just “management.” The development team and the product manager work together to monitor their progress with a positive, goal-driven, and team-based mentality.