What I’ve learned about product iteration planning while building SDKs

In my day to day at Nutrient, I work with engineering teams to build SDKs and APIs that help developers integrate document viewing, processing, and management into their platforms. Over time, I’ve come to appreciate just how much of an iteration’s success (or failure) comes down to the planning phase. Even in short, focused development cycles — as modern product practice encourages — delivery often drifts from expectations. That drift, I’ve learned, is often a result of how we set the stage.

This post is a reflection on what I’ve learned planning and shipping SDK iterations — and how I try to avoid the usual traps.

Defining iteration

When I talk about a product iteration at Nutrient, I mean a single, scoped delivery cycle, usually taking one month. One iteration typically delivers multiple usable chunks of functionality — like a new document conversion format, a performance improvement for a viewer, or APIs for user interface (UI) theming. Each improvement or new functionality goes through a cycle of refinement, building, testing, and release to gather customer feedback.

Because we ship SDKs, our iterations require more than meeting deadlines. We must maintain backward compatibility, clear documentation, and developer-friendly interfaces, so that every release becomes a foundation our users build upon.

Planning: Scope-driven or time-driven?

We tend to plan around scope first — what value can we deliver to developers in the next cycle? — but with our fixed iteration duration (for predictable releases to customers), we must adjust the initial scope to fit time constraints. This principle also applies during execution; if we spot risks to delivering the initial plan, we evaluate how to trim scope while still delivering customer value and gathering feedback.

Regardless of which side leads, one truth applies: You can’t cheat the scope–time–quality triangle. If we try to fix time and scope, quality takes the hit. In a developer-facing product, degraded quality means support escalations, technical debt, and broken trust. Like any debt, technical debt must be paid back, and its interest compounds over time.

Common planning pitfalls, and how to deal with them

Through years of planning SDK iterations, I’ve identified five recurring pitfalls that consistently derail even the most well-intentioned teams. These issues cut across organizations and experience levels, appearing in subtle ways that compound over time. Recognizing them early — and knowing how to address them — can mean the difference between a smooth delivery and a last-minute scramble.

1. Lack of clear prioritization

Every iteration starts with priority. Without it, we’re just shuffling backlog tickets and reacting to the loudest voice in the room.

There are multiple techniques to prioritize the backlog, but reality shows that none will work if we don’t stick to the rules. If stakeholders don’t agree to the prioritization logic — or worse, don’t respect it during the iteration — we get chaos. This is why, in the planning preparation stage, we gather input to understand current customer needs, as well as possible future needs (e.g. an urgent bug fix or functionality needed to unblock customers in their planned production release) and impact. This is also a moment to present our planning proposal and find a solution together. For example, maybe we won’t be able to plan a particular task or bug for this iteration, but it can be done next month. In this way, stakeholders can adapt to this plan and we all avoid disappointments.

Of course, software development isn’t a factory assembly line. Unexpected issues arise, requiring flexibility to handle exceptions. But if we allow exceptions too often, it’s no longer about prioritization.

2. Estimation without context

During planning, we rely on estimates that often differ significantly from the actual effort required. Accuracy improves over time and experience, especially in the case of similar tasks. This is why we decided to reduce the risk by investing in more detailed refinement. It means better understanding of both the problem and the solution, including technical proposals and proofs of concept (POCs) to derisk solutions and avoid dead ends.

Breaking work down into smaller, value-driven tasks also brings significant benefits. This approach provides better granularity from the customer’s perspective, beyond just work organization. It proves especially valuable when scope adjustments are needed to meet deadlines — preventing situations where entire features must be postponed.

3. Wishful planning

No one likes hard conversations. A common mistake is trying to keep everyone happy — engineering, sales, and customers — by accepting overscoped iterations and hoping it will “just work out.” It never does.

Instead, I’ve learned to embrace early confrontation. When we’re uncertain about delivering something in the next iteration, we communicate it clearly. By providing complete context — including risks, dependencies, and possible alternatives — we can develop backup plans together. Even if this challenges stakeholder expectations, early awareness allows for better adjustments and causes less frustration than last-minute disappointments.

Additionally, having a clear and limited scope gives the team a focused view of priorities, helping avoid constant context switching and interruptions. Most importantly, clear expectations and priorities help prevent the team from becoming a feature factory, making space to focus on strategic initiatives.

Planning for best-case scenarios doesn’t make them more feasible. It just makes failure less visible until the very end.

4. Missed dependencies

A common problem in iteration delivery is lack of planning for dependencies that are “outside” the iteration itself (e.g. dependence on other teams working in different iteration cycles). We learned that it’s worth spending more effort in the refinement stage to discover them early on.

Second, once discovered, before iteration planning, we ensure the dependency is handled in a way that enables delivery within a realistic timeframe. If something needs to happen before, it needs to happen before, even if it means moving the feature to the next iteration. Otherwise, you deal with the wishful planning described in the previous point. If we don’t resolve dependencies upfront, they become last-minute blockers — or worse, release surprises.

5. Overestimating capacity

This is perhaps the most common trap I’ve seen. We plan an iteration as if it’s the only thing happening, but in reality, the team is constantly juggling maintenance, support, internal tooling, and dependencies from other teams.

For example, if we know a major customer is rolling out a new version, we expect an influx of support requests. We plan for this potential surge by reducing planned scope or reserving buffer time.

We also factor in high-risk technical debt refactoring. When a module rework affects core functionality, it requires additional care in review and quality assurance. This isn’t pessimism — it’s pragmatism. If the anticipated risks don’t materialize, we can accelerate other planned work.

Closing thoughts

Perfect iterations don’t exist — but well-planned ones get closer.

Working on SDKs means we can’t afford to “just ship and fix later.” Every release is a building block for someone else’s product.

That’s why I’ve learned to treat iteration planning with utmost seriousness — preparation is essential. This applies both to developing technical solutions and to communicating effectively to gather input and understand impact.