DEV Community

Cover image for Being Your Own Product Owner
Manuel Spagnolo
Manuel Spagnolo

Posted on

Being Your Own Product Owner

As some of you1 might have realized, I am not writing any articles recently. I could state a lot of different reasons why (and some of them will be material for upcoming blog posts, by the way), but the main concrete reason for it is that I am spending most of my spare time creating my blog.

Whether the world needs another dev-tech-geeky blog made with Gatsby is highly arguable, but what is interesting for me is the process.

As opposed to my stereotypical pet project, I am trying to stick with a "business-like" process.


Following what I learned from this awesome book, I have split the design of this product into layers, allowing me to get to the design phase with a lot of light already shed.

The document I produced can be found here.

As you can see, the document is far from the level of details discussed in the book and way more simplistic. Nonetheless, it turned out to be a huge productivity boost for me. With development (and music and other things within my comfort zone) it was crystal clear which kind of difference a proper plan could make. With design, for me, it was mindblowing.

Mindblown GIF

The main focus during this phase has been forgetting I am a developer, forget technical constraints and try as hard as I could to think like a designer.

This led me to produce the design you can see here.

Owning the product

If shifting from the Developer to Designer has been hard, shifting from Developer to Product Owner is actually being even harder.

Although I thought I knew what to expect from a good user story, producing a good one is actually a completely different story (pun intended).

This is the board I am working with.

Why this post?

Well, as my own Product Owner I feel a bit at loss right now.

Maybe I am introducing too much boureaucracy in the process, but I really struggle in dividing my Developer self from my Product Owner self and this is exactly why I am asking for your help.

As developers, what would you like to see in a board like this? What is missing?

As product owners, can you suggest any good resource to learn how to write kickass stories and tickets?

Thank you all!

If you were still wondering, the code is still in a very bad shape, but as soon as I reach the v0.0.1 milestone, I will open source it.

1. It's actually a lot of you ❤ I never would have thought of having ~3.5k followers. Thanks to each and every one of you!

Discussion (5)

bertilmuth profile image
Bertil Muth

Hi Manuel. As you are producer and consumer of the stories, my advice is: think about what level of documentation do YOU really need? For example, what are the things you tend to forget easily? What are the things where you think it retrospect: a bit more planning would have helped? So: plan in time for your personal retrospective.

shikaan profile image
Manuel Spagnolo Author

Thank you Bertil for this (:

My problem is exactly what you described: stories as they are right now are perfectly fine for me. However, the sole reason why this holds true is that the whole lot of hidden assumptions I make are shared between the producer and the consumer, so to speak.

Therefore, although my stories are serving the scope right now, I don't feel like I am being a good PO, as I am fairly sure no one besides me could understand my board.

This is the reason why I was after some good resources/frameworks/book to help me discover and clarify what I am assuming without even being aware of that

bertilmuth profile image
Bertil Muth

Since you‘re looking for recommendations, one good source for a lot of Product Management ideas is Roman Pichler. Here’s an example: One trait of a good product owner is that she’s doing what’s necessary depending on context. As long as you’re the only consumer, lots of implicit knowledge is fine. If you want to communicate with others, it’s a different story.

Thread Thread
shikaan profile image
Manuel Spagnolo Author

Thanks again Betril, I'll definitely look into this (:

fnh profile image
Fabian Holzer

The big promise, at least of the early agile movement was, to use a phrase attributed to Kent Beck, "healing the divide between development and business". This division had (and has) a negative impact, and therefore introducing it artifically in a "team of one" is to some extend, if not counterproductive, then at least pointless.

But, in your pursuit to deliberatly practice the business analyst/product owner/manager role, may I suggest to consider something that has become a bit of a lost art: writing up a software requirements specification in a more formal manner than "user stories". The story format originally was intended as a "promise for a future conversation" between people closely working together. A perferctly legitimate tool, albeit not as a replacement for a spec, and again a bit pointless in a team of one.

Here a few suggestions for skills/traits, that I could imagine, would make a product manager/business analyst, that many developers would be thrilled to work with:

  • Writing up good use cases, instead of "user stories". For example Alastair Cockburns "Writing effective use cases" is still a very good book on that subject.
  • Using the behaviour driven development approach to create an executable form of a specification
  • The concept of the "ubiquitous language" of the domain-driven design movement is something that I personally value greatly
  • Sketching UIs (and involving devs in the ideation phase)