The development phase is where design and specifications turn into working software. Ideas become real, theoretical possibilities meet practical constraints, and plans collide with the complexity of implementation. For the product manager, this is also where the role shifts. The PM is no longer the person driving a specification forward — the engineers are. The product manager workflow during development is closer to that of a coordinator: removing blockers, holding clarity steady, and adapting the plan as reality reveals itself.
Effective development depends on three things working at once. Clear inputs from the earlier phases. Skilled engineering execution. And the continuous coordination needed to handle the unexpected situations that always show up during implementation.
The PM’s work during development covers five areas: planning the schedule, frontend development, backend development, quality control and quality assurance, and managing the schedule as reality diverges from the plan.
Planning the Development Schedule
Why Schedule Planning Matters Despite Uncertainty
Development estimation is famously uncertain. Software is complex, and complexity produces surprises. Yet despite this inherent uncertainty, schedule planning still earns its place.
A schedule forces the team to think explicitly about what the work actually involves. Dependencies and sequencing requirements surface. Checkpoints appear where progress can be evaluated. Other functions of the business — design, marketing, support — can plan around dates that are at least defensible.
The goal is not perfect prediction. It is a reasonable starting hypothesis that can be updated as reality reveals itself.
Roles, Deliverables, and Cross-functional Coordination
| Role | Responsibility |
|---|---|
| Engineers | Estimate development effort, identify technical dependencies and risks |
| Product Manager | Own the overall timeline and coordination, help adjust priorities when scope exceeds capacity |
Designers need to understand the development schedule so they can time their handoffs. Marketing needs the schedule to plan launch activities. When several engineers are working in parallel, everyone needs shared visibility into who is doing what, and when.
| Category | Focus area | Key deliverables |
|---|---|---|
| Work breakdown | Scope and dependencies | Features and components that need to be built, an estimate for each item, technical dependencies between components, external dependencies (design, APIs, third-party services) |
| Timeline | Milestones and coordination | Start and end dates for the major deliverables, progress milestones, integration points where components come together, a stabilization window before release |
| Risk identification | Technical and external uncertainty | Technical areas with estimation risk, dependencies on external parties or systems, parts of the requirements that may still shift |
Estimation Approaches
Different situations call for different estimation methods, and each has trade-offs.
| Approach | Best for | Limitation |
|---|---|---|
| Time-based estimation (hours, days) | Well-understood work with low uncertainty | Tends toward optimism on complex tasks |
| Relative sizing (story points, t-shirt sizes) | Comparing items against each other | Needs calibration to translate into calendar time |
| Range estimation (best / likely / worst) | Work where uncertainty needs to be made explicit | Harder to communicate and aggregate |
| Timeboxing | Exploratory work with high uncertainty | The full scope may not be completed |
Whatever approach you use, building in a buffer for unexpected issues improves the reliability of the schedule. The question is never whether surprises will happen — they will. The question is how much room you have left to absorb them.
Planning a development schedule is a bit like planning a move. You can roughly estimate how long it takes to pack, transport your things, and arrange them in a new place, but you cannot predict an elevator breakdown or a rainstorm on moving day. What matters is not a perfect timetable. It is having the right sequence (pack, transport, arrange) and enough slack to handle what you did not plan for.
Frontend Development: Where Design Meets Reality
Why Frontend Quality Shapes Perceived Product Quality
Frontend development builds the part of the product that users see and touch. Visual presentation, interactions, and client-side behavior all live here. This is the layer where design meets reality. It is where users form their first impressions, where usability is felt rather than described, and where perceived product quality is decided.
Good frontend work has to balance several things at once:
- Visual fidelity to the design
- Performance and responsiveness
- Accessibility for users with different abilities
- Cross-browser and cross-device compatibility
- Maintainability for future changes
Trade-offs between these are routine. A pixel-perfect interface that is sluggish or inaccessible has failed the user, even if it matches the mockup.
Key Deliverables: Implemented Interface and Code Quality
| Category | Focus area | Key deliverables |
|---|---|---|
| Implemented interface | UI fidelity and compliance | Every screen and component built to the design specification, interactions that behave as defined, responsive layouts across the supported screen sizes, accessibility that meets the agreed criteria |
| Code quality | Maintainability and standards | Well-structured, readable, maintainable code, appropriate automated test coverage, documentation for the more complex components, consistent patterns that match the team’s conventions |
Think of frontend development like the front-of-house service in a restaurant. The kitchen can make excellent food, but if the service is slow, the tables are messy, or the menu is hard to read, the experience suffers. Frontend is the most direct point of contact users have with your product. It decides how the product tastes.
Backend Development: The System That Powers the Product
Why Backend Reliability Determines Real Capability
Backend development builds the systems that power the frontend — data storage, business logic, integrations, and services. Users do not see this layer directly, but everything they do depends on it.
The backend decides what is actually possible. It handles data storage and retrieval, business rules and calculations, security and access control, integrations with external systems, and performance under load. A beautiful frontend on top of a fragile backend produces a product that looks good but fails at exactly the moments that matter.
Key Deliverables: Working System, Documentation, Code Quality
| Category | Focus area | Key deliverables |
|---|---|---|
| A working system | Core functionality and integration | A database schema that implements the required data model, APIs that support the frontend and any other consumers, business logic that meets the product requirements, integrations with the external services the product depends on |
| Documentation | System clarity and maintainability | An entity relationship diagram (ERD) that shows the data structure, an API specification detailing endpoints, parameters, and responses, system architecture diagrams that show how components relate, operations documentation for deployment and maintenance |
| Code quality | Reliability and standards | Well-structured, maintainable code, appropriate automated test coverage, security best practices applied, performance considerations addressed |
Backend development is the foundation work of a building, along with its plumbing and electrical systems. The tenants only see the interior, but a weak foundation tilts the whole structure, and bad plumbing leaks where you cannot see it. The reliability of a product is decided in places users never look.
Quality Control and Quality Assurance (QC/QA)
Why Testing Cannot Be Skipped
Testing verifies that what was built actually works the way it is supposed to. Skipping this step, or rushing through it, almost guarantees that problems will reach users.
Bugs that reach users damage trust, create support load, and sometimes cause real harm. Testing catches these issues before they get out.
Beyond finding bugs, QA verifies that:
- Requirements were implemented correctly
- Edge cases are handled appropriately
- The product works across different environments and configurations
- Performance meets acceptable thresholds
- There are no obvious security vulnerabilities
Roles, Deliverables, and Acceptance Testing by the PM
Quality is a shared responsibility, but each role has a different angle on it.
| Role | Responsibility |
|---|---|
| Engineers | Write automated tests, perform code reviews, fix identified issues |
| Product Manager | Verify that requirements are met and run acceptance testing |
| Designers | Verify that the implementation matches design intent |
Anyone who contributed to a requirement or specification should confirm that their part was implemented correctly. This is the principle: whoever wrote the intent verifies the result.
| Category | Focus area | Key deliverables |
|---|---|---|
| Issue documentation | Defect transparency | Bug reports with clear reproduction steps, severity and priority assessments, the environment and conditions in which the issue occurs, an explicit comparison between expected and actual behavior |
| Test artifacts | Verification assets | Test cases that cover core functionality, automated tests that prevent regression over time, documented test results that show what was verified |
| Quality validation | Readiness and sign-off | Confirmation that product requirements are met, formal sign-off against defined quality criteria, an explicit record of known issues with the decision made on each one |
Systematic Issue Tracking with Reproducible Bug Reports
Issues that get found need to be tracked systematically, with enough information to resolve them. A good bug report does not just say “this is broken.” It includes everything someone needs to reproduce the problem and judge its severity.
| Field | Purpose | Example |
|---|---|---|
| Title | A short description of the issue | “Login silently fails when password contains special characters” |
| Reporter | Who found the issue | Soojin Kim |
| Environment | Where the issue occurs | Staging, Chrome 120, macOS |
| Reproduction steps | How to trigger the issue | 1. Go to login page 2. Enter a password containing “&” 3. Click login |
| Expected behavior | What should happen | The user logs in successfully |
| Actual behavior | What actually happens | The page refreshes with no error message, login does not complete |
| Severity | How serious the impact is | High (core flow blocked) |
| Screenshots / logs | Supporting evidence | [Attached] |
QA is the inspection step before a car leaves the factory.
- You do not assemble a car and ship it straight to a customer.
- You check the brakes, the steering, the electronics.
- You take it for a test drive.
Software needs the same kind of deliberate verification before it gets to users.
Managing the Development Schedule When Reality Diverges
Why Early Visibility into Delays Matters
Development delays produce knock-on effects. Launch dates slip. Marketing campaigns need to be rescheduled. Commercial commitments may be at risk. Early visibility into a delay is what makes adaptation possible — when there are still options available, you can choose between them.
Understanding why a schedule changed is just as important as knowing that it changed. If estimates have been consistently optimistic, that pattern needs to feed into future estimates. Otherwise the team learns nothing and repeats the same miss.
Tracking Progress and Documenting Schedule Changes
| Role | Responsibility |
|---|---|
| Engineers | Report progress honestly and surface blockers early |
| Product Manager | Track the overall timeline and coordinate the response to changes |
Designers need to know whether a development delay affects their review timing, and stakeholders with launch commitments need updated expectations.
| Category | Focus area | Key deliverables |
|---|---|---|
| Progress visibility | Tracking and projection | The current status of each development item, planned versus actual completion dates, a projected completion date based on the current rate of progress |
| Change record | Transparency and decision tracking | Documented reasons for schedule changes, an impact assessment on the overall timeline, a record of the decisions made in response |
Writing changes down matters more than it might seem. A schedule change without a documented reason is invisible to anyone who joins later, and it leaves the team unable to learn from a pattern of misses.
Common Causes of Development Delay and How to Respond
Development delays usually come from a small set of recurring causes. Each has its own prevention and its own response.
| Cause | Prevention | Response |
|---|---|---|
| Requirement changes mid-development | Freeze requirements before development, batch changes | Assess impact, then negotiate scope or schedule |
| Underestimated complexity | Include buffer, split work into smaller pieces, investigate uncertain areas upfront | Re-estimate remaining work, adjust the plan |
| Technical debt or unexpected issues | Reserve time for the unexpected, investigate unknowns early | Assess severity, then resolve immediately or defer |
| Integration problems | Define integration points early, integrate incrementally | Find the root cause, allocate resources to resolve |
| External dependency delays | Identify dependencies early, prepare contingencies | Escalate, find workarounds, adjust the schedule |
| Resource availability | Account for meetings, support, and other demands | Adjust expectations, protect focused time |
Most of these come down to the same underlying habit: assuming the plan will hold. The teams that handle delays well treat the plan as a hypothesis from the start.
Building a Culture of Honest Progress Reporting
Development progress is genuinely hard to assess. Work reported as “90% done” frequently contains 50% of the remaining complexity — the last stretch is almost always harder than it looks.
Honest progress reports depend on a few cultural conditions:
- Psychological safety to surface problems without blame
- A culture that focuses on solving problems rather than assigning fault
- The shared recognition that accurate information is valuable even when it is bad news
- Consistent behavior that shows early warnings are welcomed, not punished
Teams that punish bad news learn to hide problems until they become crises. Teams that handle bad news constructively surface problems while they are still manageable.
Managing a development schedule is closer to pacing a marathon than running a sprint. Almost no one runs 42 kilometers at the pace they planned at the start. What matters is reading your current pace accurately and adjusting for the distance that remains. “I’m doing fine” followed by a collapse at the 35-kilometer mark is much worse than “I’m slower than expected and need to adjust” at the 20-kilometer mark.
Conclusion
The product manager workflow during development comes down to two things: removing blockers and maintaining clarity. Engineers do the building. The PM keeps the path in front of them clear and the picture of where the work is going honest.
The work is not about producing a perfect plan. It is about building a system that can adapt when reality differs from the plan — because it always will. A schedule that gets updated honestly is more useful than a schedule that gets defended dishonestly. Tests that catch issues before users do are cheaper than the trust they save. And a culture where bad news travels early is the foundation that makes everything else above possible.
The next phase in the product lifecycle is launch and marketing — preparing the release, coordinating marketing activities, and analyzing the data that comes back. That is where the work of development meets the world, and where a different set of coordination challenges begins.
Leave a Reply