When a Project Starts to Feel More Like a Product
Lately, I’ve been thinking about how often some initiatives are framed as projects, even when they feel much closer to products.
What I mean by that is simple: they have users, they solve ongoing problems, and their value depends on whether they continue to work well over time. That feels different from a one-time delivery. It feels more like something that needs iteration, feedback, prioritization, and a clearer understanding of the outcome it is meant to support.
The more I’ve been exposed to product thinking, the more I’ve started noticing this distinction.
It has changed the way I think about work that happens outside of traditional tech environments. In those spaces, it can be easy to focus on timelines, deliverables, and implementation. Those things matter, of course, but product thinking asks a slightly different set of questions: Who is this really for? What problem is it solving? How will we know it is useful? And how does it connect back to the bigger goal?
For example, a team might set out to improve an internal workflow or build a new tool to help people access and manage information more effectively. At first, that work may be framed as a project: define the scope, gather the requirements, deliver the solution. But in practice, it often behaves more like a product. Different users interact with it in different ways. Adoption matters. Usability matters. The solution may need to evolve as needs change. Success is not just whether it gets launched, but whether it continues to be useful.
What I keep coming back to is how difficult that connection can be when the north star is clear in theory, but much less clear in practice.
Sometimes the broader goal is well understood at a strategic level, but not translated in a way that makes day-to-day decisions feel obvious. When that happens, ownership can feel blurry. Priorities can become harder to defend. And implementation can drift away from the original intent, not because teams are not trying, but because the through-line is harder to see.
Get Pragya Jolly Singh’s stories in your inbox
Join Medium for free to get updates from this writer.
I’ve also been thinking about how much environment shapes what product thinking can actually look like.
In governance-heavy environments, moving quickly is often not the point, or at least not the only point. There are more considerations early on. More people involved. More requirements to satisfy before something gets tested or explored. That can make experimentation feel slower, especially compared to the way prototyping is often talked about in tech.
Using the same example, a team in a fast-moving tech environment might test a lightweight version quickly and learn from real user feedback. In a governance-heavy environment, even an early proof of concept may require security assessments, accessibility assessments, and a stronger justification for the use case before it can move forward. That changes the shape of experimentation itself. A proof of concept is no longer just a fast way to test an idea; it also becomes something that must demonstrate safety, usability, and legitimacy early on. Teams are not only asking, “Could this work?” They are also being asked, “Is this secure enough to explore? Is it accessible enough to consider seriously? Is the use case strong enough to justify the effort?” Those are valuable questions, but they also mean that learning can take longer and require more buy-in before the first real test happens.
But I don’t think that automatically makes it worse.
If anything, it has made me think more carefully about what speed is actually optimizing for, and what rigor is protecting. Sometimes moving slower means more scrutiny, more alignment, and a better chance that what gets built will actually be useful and sustainable. Sometimes it means the opposite. The point is that the tradeoff is real, and pretending every environment should work the same way misses that.
I think that is the part of product management I’m appreciating more lately: it is not a fixed formula.
There isn’t one correct version of product management. The shape it takes depends on the environment. What matters is whether the approach fits the problem, the users, and the constraints around it.
Product thinking adapts to context.
