Product Leadership | Concept to Cloud
New! Listen to Concept to Cloud - Real stories from the trenches of software engineering

Product Leadership On Demand

Decide what to build,
before you build it.

Roadmapping, product management, and UX research and design. Run by Amelia, Director of Product, certified product manager, and the person who built a research platform now used by 400+ organizations.

Fractional · Advisory · Retainer

Talk to our team
Amelia Prasad
400+
Organizations on the platform she built
CPM
Certified Product Manager
NASA
Atmospheric science before product

Meet Amelia

A scientist who went into product to build for the people the research was for.

Amelia came to product from atmospheric science and astrophysics. She worked as an atmospheric scientist at NASA and holds a published astrophysics background, before deciding the systems she wanted to change were gated behind grants and policy rather than reaching the people the change was actually for. Product became the way to build for those people directly.

She works most naturally in ambiguity: the 0 to 1 space, where the product, the workflow, and the definition of success don’t exist yet. At Princeton’s School of Public and International Affairs she built a research platform from scratch that now serves more than 400 organizations worldwide. On that engagement she held UX research, interface design, and product management as one role rather than three.

Most recently that meant designing the schema editor for Saiku, where no tool for the job existed, so she built the foundation underneath it from scratch. As Director of Product she leads product and design across every Concept to Cloud engagement: technical enough to go deep with engineers, broad enough to hold the whole mission.

“Most teams don’t have a build problem, they have a decision problem. They can ship, they just can’t agree on what. The work I like most is the part before there’s a roadmap at all: figuring out who it’s really for, what would actually change for them, and what we’re deliberately not doing. Everything after that gets easier.”

, Amelia Prasad

Who it’s for

Product leadership that meets you where you are.

Nothing exists yet

You have a problem worth solving and no product, no workflow, and no agreed definition of success. This is the 0 to 1 space, and it is where the leverage is highest.

Engineering is waiting on decisions

The team can ship, but the roadmap keeps moving and scope arrives half-formed. You need someone to hold the direction steady so delivery stops absorbing the ambiguity.

The domain is genuinely hard

Data-heavy, technical, or regulated systems, where the interface is where complexity either gets resolved or gets handed to the user. Generalist product help tends to stall here.

What you get

Three disciplines held as one role, not passed between three people.

Roadmapping

A direction you can defend

What gets built, in what order, and what is deliberately not being built. Sequenced so engineering can plan against it and stakeholders can argue with it before it is committed rather than after.

Product management

Scope that holds

Discovery with the people who will actually use the thing, requirements that survive contact with engineering, and the day-to-day judgement calls that keep a build from drifting.

UX research & design

An interface that resolves the complexity

Research, interaction design, and the interface itself. In complex domains this is not decoration; it is where the hard parts either get solved or get passed on to whoever has to use the system.

Why one person rather than three

Most engagements split product, research, and design across separate people, and the seams between them are where intent gets lost. Held as one role, the person deciding what to build is the same person talking to users and drawing the interface, so the decision and its consequences never get separated. On the Princeton platform that is exactly how it ran, and it is the shape we default to.

How engagements run

Three shapes, depending on how much of the problem is yours to hold.

Fractional

A share of a Director of Product, ongoing. Direction, delivery, and design across your roadmap, at a cadence that fits the size of the work.

Advisory

Lower cadence, higher altitude. Your team runs the work; we pressure-test the direction, the scope, and the decisions that are expensive to get wrong.

Retainer

Ongoing availability for a body of work with no fixed end date. Useful when the roadmap is live and the questions keep coming rather than arriving in a block.

Questions you’ll probably ask first

What does product leadership actually cover?

Roadmapping, product management, and UX research and design. In practice that means deciding what gets built and in what order, running discovery with the people who will use it, designing the thing, and holding scope steady while engineering ships. On smaller engagements it's all one person; on larger ones it's direction plus a team.

How is this different from hiring a product manager?

A product manager executes against a direction that already exists. Product leadership sets the direction: what the product is for, who it serves, what success means, and what you are deliberately not building. If you already know all of that, you need a PM. If you are still arguing about it, you need this first.

Do you do the design as well, or just the product side?

Both. Product management, UX research, and design run together rather than as a handoff between separate people. For data-heavy and regulated systems that matters, because the interface is usually where the complexity either gets resolved or gets passed on to the user.

We do not know what we are building yet. Is it too early?

That is the best time. The 0 to 1 space, before the product, the workflow, or the definition of success exists, is the work we do most naturally. Coming in later is fine too, but coming in early is where the leverage is.

Will you work alongside our existing product or design people?

Yes, and that is the most common shape. Working alongside an existing PM or designer, or setting direction that your team then runs with, is more usual than replacing anyone.

How does an engagement start?

A conversation about what you are trying to build and what is currently in the way. If we are a fit we will scope shape, cadence, and price from there. If we are not, we will say so.

Every engagement starts with a conversation.

Tell us what you’re trying to build and what’s currently in the way. If we’re a fit, we’ll know quickly. Need engineering leadership alongside the product side? We also run combined product and engineering leadership as one embedded team.

Talk to our team