Using Scrum on small projects where Owner doesn't want to be involved

Question

Recently I've been reading and learning quite a lot about scrum and I like it a lot. However, I do have a couple of likely scenarios in my head to which I don't know the solution. So let's say that I might want to organize an agile team of (for instance) four web developers (one of them UI/UX designer). This team would operate on scrum principles.

Initially we would probably be working on projects like landing pages for ordinary people's small businesses, like renting apartments, selling cookies... Such customers simply can't be set with Product Owner role (IMHO), because they usually expect to hire a company, give them the overall project goal with some details, and then expect the job to be done (including a lot of decision making) with as little of their involvement as possible (in their opinion, they have more important things to do). Let's say I'd like to engage myself in a developer/scrum master role (I know that even that is debatable, being a team member and scrum master at once), so I simply shouldn't take the role of the product owner as well.

So as for my questions: If I'm my company's business owner, do I simply need to be a product owner as well (do these roles include each other)? Can I employ a sales person which might have the product owner role? Would it be better if it is an experienced developer instead of a sales person? Is this even a smart move? Lastly, is there another agile approach that might better suit my position?

---

EDIT: Thank you everyone for good inputs. I added some comments, any aditional info will be greatly appreciated.

Answer 1

I think that your situation its in fact very common, a lot clients don't to be involved with the level of dedication that a PO role needs.

Its very usual the approach of the "PO proxy", this is someone of your company that talks with the client and translates the requirements of the client into user histories for the scrum team. Off course you need to, little by little, involve more a more your real client into your process, but this is not always possible and depends a lot in your type of clients, the "PO proxy" can be a reasonable solution in most scenarios.

For this position the best fit its probably not a developer, and probably not a sales people, the best fit its a domain expert in the business of your client (at the same time can be a developer or sales, but his main skill its to be a domain expert).

Other thing to consider its if you really need a person full-time with this role, or if this role can be shared with other task, this again depends a lot on your particular context, you can begin with a shared or full-time role and "inspect and adapt" to your particular needs.

Answer 2

In my experience, if you tell the client they're the 'product owner', they tend to revolt at the extra responsibility. But if you say you're going to show them your progress every couple weeks so they can direct the team, they're cool with it. For the most part, that's what the product owner does anyway.

Answer 3

I would say that your external client is a stakeholder and your product owner should come from within your own organization.

In my experience, business owner and product owner are rarely the same role. To check on the skills required of a Product Owner, as well as their responsibilities, look no further than the Scrum Guide.

Do choose your product owner with care. They will have a significant impact on how well you achieve the benefits of scrum.

Answer 4

I have been in similar situations and we never gave the the responsibility of the product owner to the client. As you said the client will not want to undertake this responsibility. It requires to much effort from their side, and it is not considered best practice.

You should have a product owner that is part of your team and makes sure that the team delivers what the client asks for. And more important, acts in the interest of your team. She should have enough expertise to understand the client and judge the priorities and the importance of the features asked from the client.