TL;DR

• Define what is fixed, what is flexible, and what you are trying to learn at the start of every concept development project, not during it.
• Budget checkpoints at each third of the project let you manage health without micromanaging exploration.
• The client’s stated need and their real need are often different; find out what the output needs to do before the work begins.
• Flexible scope is a tool, not a permission slip: changes should serve the core problem, not expand it.
• IP timing decisions belong in the project plan. Raise them early, before external disclosure creates problems.

Early phase concept development is a weird part of a project lifecycle. It is often the most exciting phase, because the team is exploring possibilities, generating new ideas, and turning a fuzzy opportunity into something real. It is also one of the hardest phases to manage, because the very thing you are trying to create is still being discovered and so the project direction tends to bend and sway day-to-day.

The challenge for the project manager is to create enough structure that the project does not drift off course, without creating so much structure that the team loses room to follow the most promising path or pivot based on what they learn. Further, management control needs to match the purpose of the work: giving the team free rein creates confusion and budget risk, but micromanaging can kill the learning that concept development is supposed to produce.

Here are the main things I aim to make happen when managing early phase concept development.

Concept Development Scope Should Flex, Not Drift

Early concept development needs flexible scope. The purpose of the work is usually to explore, learn, and converge. That means the team may discover that an assumption was wrong, a feature is less important than expected, a risk is bigger than expected, or a completely different concept is stronger than the original direction.

This is not scope creep in the traditional sense. It is often the work doing what it is supposed to do.

How: At the start of the project, define the boundaries more than the exact path. A good early phase understanding might include the problem being solved, the intended use, the target user or stakeholder, major constraints, known risks, and the decision that needs to be made at the end of the phase.

A useful framing is: what is fixed, what is flexible, and what are we trying to learn?

Pitfall to avoid: Flexible scope should not mean unlimited scope. It should not mean every new idea gets chased, every stakeholder suggestion gets added, or every interesting technical rabbit hole becomes part of the project. The scope can flex, but it still needs to flex around the project objective.

A good test is whether the change helps answer the core problem at hand. If it does, it may be worth considering. If it does not, it probably belongs in a parking lot.

Check Budget Health by Thirds, Not Task by Task

One of the hardest parts of managing early concept development is knowing whether the project is on track. In a detailed implementation project, you can often compare completed tasks against the plan. In concept development, that can be misleading, because the plan itself may be changing as discoveries are made.

Instead of trying to control every task too tightly, check in on the budget roughly every third of the way through the work.

How: Break the project into thirds from a budget and effort perspective, not necessarily from a strict task perspective.

At the first third, the question is: are we learning the right things, and does the original direction still make sense?

At the second third, the question is: are we converging, or are we still opening up new questions?

At the final third, the question is: what do we need to finish, reduce, defer, or stop so that we land the project responsibly while delivering to the program needs?

This gives the team room to innovate early, while still creating meaningful project health checks. You are not asking the team to justify every hour against a rigid task list. You are asking whether the amount of learning, progress, and convergence matches the amount of budget consumed.

Pitfalls to avoid: Do not use the one-third check-in as a hidden detailed estimate. If every check-in becomes a line-by-line interrogation, the team will naturally become conservative and stop exploring.

However, if the project reaches the later third and it is clearly trending over budget, it is appropriate to become more granular. At that point, the management style should shift. The team should be clearer about what remains, what matters most, and what can be descoped or deferred. Early flexibility is useful; late ambiguity is dangerous.

The Stated Need Is Rarely the Real Need

In early concept development, the stated need is often “create concepts.” But the real need may be something different.

Often, the client does not just need concepts. They need to complete a milestone. Often this requires something tangible enough to support a decision, raise more funds, align internal stakeholders, attract partners, or prove that the opportunity is worth continuing.

This is a critical distinction. A concept package for internal brainstorming is not the same as a concept package to support a seed funding round. A rough prototype for technical learning is not the same as a prototype that quantifies core performance.

How: At the start of the work, ask what the client needs to do with the output.

Good questions include: Who needs to believe in this? What decision are they trying to make? Is there a funding milestone? Is there a board meeting, investor pitch, grant deadline, strategic review, or partner discussion? What would make the concept feel real enough for that audience?

Once that is understood, tie it directly into the timeline. If the client needs a tangible demonstration by week eight, then the project cannot discover that requirement in week seven. The work needs to be shaped around that moment from the beginning.

Pitfalls to avoid: Don’t be tempted to make unrealistic promises. The goal is not to over-polish the concept or hide uncertainty. The goal is to package the work in a way that is tangible, credible, and appropriate for the stage of development.

A concept that looks too finished can create its own risk, especially if stakeholders mistake it for a near-final design. Be clear about what has been proven, what is assumed, and what still needs to be tested. As an example, a highly polished prototype or rendering may lead stakeholders to believe the core technology is already well-defined, when in reality key technical risks are still unresolved. This can create pressure to push the project into a later development stage too quickly, skipping critical technology definition and de-risking work. The result is that those core issues resurface later, when documentation expectations are higher, changes are more expensive, and the overall budget impact is significantly greater.

IP Timing Is a Concept Development Blind Spot

Early concept development can overlap heavily with intellectual property. New concepts, mechanisms, workflows, user interactions, or technical approaches may create opportunities for protection.

The project manager does not need to act as a patent lawyer, and not every project will need IP support. However, it is worth regularly checking whether the main stakeholder needs help thinking about IP timing and process.

How: Build in a simple check-in with the main stakeholder early in the project and again when concepts start to converge. The question can be straightforward: do you need support from IP counsel before this concept is shared more broadly?

This is especially important before external presentations, fundraising discussions, conferences, publications, public demos, or partner conversations. If the client may want to pursue protection, they should have the chance to speak with appropriate counsel before disclosure decisions are made.

Pitfalls to avoid: Do not over-promote the IP opportunity too early. A concept may feel novel to the project team, but that does not automatically mean it is protectable, valuable, or even usable without issues. There may be existing work or patents that limit what can be protected, or that restrict how the idea can be used or developed further. The project manager should position IP as something to assess, not as a guarantee of protection or exclusivity.

Related Resources