I'm working on the case study for a PO interview and trying to do my best interpreting the instructions.

I'll be coming up with an updated user journey for part of their subscription process; I'm free to format my document as I like and include wireframes if needed.

However the recruiter said several times this is NOT a UX assignment and that UX is out of scope. What do you think I should avoid including in my proposals? Any documents that would be out of place? They were pretty insistent on that part, apparently other candidates misunderstood them in the past

The exact boundary between PM and UX is not fully clear to me, especially when describing a user journey / making wireframes which I would assume are a part of UX work.

I understand that in a real Agile environment, PM and UX would be cooperating daily from the beginning, that's not where my interrogation is. What I'm asking is more: within that cooperation, what are the jurisdiction of the PM and the UX team ? What are the documents the PM team would not produce themselves and leave to the UX ?

  • 1
    Ultimately the only boundary that matters in this case is the one in the interviewer's mind. Not sure that we're going to be able to address that here.
    – MCW
    Jun 2, 2021 at 15:58
  • 1
    It seems like they aren't saying that UX is out of scope for PM, but that UX is out of scope for the interview. My guess is that the organization has UX researchers and/or designers and you are not interviewing for one of those roles. I would interpret the request as focusing more on creating the user journey and identifying where wireframes would be useful than the specific content of the wireframes or mockups being assessed against UX principles. However, like @MCW says, only the interviewer can tell you what their (or their organization's) opinion on the boundary between PM and UX is.
    – Thomas Owens
    Jun 2, 2021 at 16:02

3 Answers 3


Product Management Sets the Vision

Product management, and specifically the Product Owner role in frameworks like Scrum, are primarily about managing the vision for a product. The day-to-day work of product management involves a lot of things such as:

  • stakeholder management
  • market and business analysis
  • product positioning
  • prioritization of features and product backlogs
  • direct or indirect budget allocations and release planning

However, none of these things should be the raison d'être for the role. Instead, an effective Product Owner should generally focus on collaborating with stakeholders, customers, and the development team to outline what should be done to deliver business value, and leave how to deliver that value to those who will actually be doing the work.

Traditional product management and agile Product Owner roles (whether Scrum, SAFe, or just "agile") do differ in scope and intent, so you won't really find a one-size-fits-all job description that works across all organizations. In all cases, though, UX design is a skill or product development activity that supports product/market fit; while there is some overlap, it should definitely not be confused with defining the vision for the product.

Some General Demarcations

For this particular role, you've already been told that "UX" (whatever that means to the client) is out of scope. Your best bet is really to ask them what they think UX means, and then avoid those things.

In general, though, a good user story map (which is often different from an interface-oriented user journey) should include what a user wants to do, not how they do it. With that in mind, some general demarcations between product vision and design would exclude:

  • wire-frames and mock-ups
  • graphics design and renderings
  • implementation-level details about the product
  • anything else that is a deliverable rather than a milestone, or an opportunity for feedback and validated learning

As just one example, the product development process might include an activity such as A/B testing of packaging, but the details of the packaging itself are not usually part of a predefined vision. Perhaps more importantly for your exercise, such details are not typically in scope for a user journey, because they aren't really things an end-user does.

If you find yourself focusing on how rather than what, you've probably crossed the demarcation. I'd strongly recommend that you focus on defining the general activities and outcomes you need to make a market fit, and leave all implementation details to the product development process.

  • Thank you. The distinction between the /what/ and the /how/ makes a lot of sense to me. I've done a bit of both in past roles, so I didn't see the demarcation clearly.
    – allad
    Jun 2, 2021 at 16:25

A project manager's primary function, in my opinion, is that of "a facilitator, a coordinator, [sometimes] an arbiter, and above all a communicator."

In my view, it is far more a human function than a technical one, and to me this is precisely why it is so important – and so easily overlooked.

"UX designers," in a software project, are "SMEs = Subject Matter Experts." They contribute their expertise to the design of the project, along with the many other equally-expert(!) members of the same team. But, you are not being called-upon to contribute to what they are doing – your role is different.

Your best perspective, if I may suggest, is to always remain at an arm's length from what they are doing, because you're not directly a part of what they're doing. Your job is to help them do it, and, in any software project, "that arm's length" is actually a very big part of it. Software practitioners are watchmakers. They need you to be minding the watchmaking shop – and to be meaningfully informing the shop's owners.


Product Management defines the vision and the high-level functionality.

In your case, what essentials are required on the User Interface, for this to be a Product Release.

UX defines what it will look like: colors, buttons or links, menu styles.

The grey area - sometimes filled in by a Technical Project Manager - are the items that need to be there for technical reasons. Items like:

  • Links to legalese
  • Reset/lost password

This will be culture dependent. Each company (and sometimes department) having rules & opinions who owns those parts.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.