A Product Manager Case Study on Walled Gardens – Part 2 Developing a User Story & Task List
In my last blog post, “A Product Manager Case Study on Walled Gardens” I created two user personas representing a customer at Tidal (the lossless hi-fi streaming service) and at Spotify (the most popular streaming platform in the world). Here is a reminder of those two personas.


- Steven owns a set of $1,800 headphones (Sennheiser HD 800 S).
- Steven owns a dedicated amplifier to drive the headphones.
- Steven paid Mercedes Benz an extra $2,400 for the Burmester 13 speaker 600 watt sound system in his car.
- Steven refuses to use Bluetooth because it lowers audio quality.
- Steven has disposable income, and always wants the best experience.
- Steven always has the newest Samsung Galaxy Phone at launch.
- Steven has a household income of $150,000 and is single.
- Steven lives in a big city with a 1 hour commute.
- Nathan Uses the earbuds that came with his phone.
- Nathan Sometimes listens to music directly out of the phone speaker when hiking or working out.
- Nathan is Excited his new car had Bluetooth so he could finally ditch his cassette tape to 3.5mm adapter from his last car
- Nathan Loves the convenience of Bluetooth.
- Nathan uses Spotify’s free tier when the subscription doesn’t fit his budget. He’d rather listen to low quality audio than none at all, convenience and access matter more to him than quality.
- Nathan uses whatever free phone his carrier gave him.
- Nathan has a household income of $65,000 and is married with a wife and kids.
- Nathan lives in the suburbs in a outskirts of a larger city.
All caught up? Great! I decided to put together a post assuming that I was the product manager or product owner at Spotify, and I had recently read this blog post seeing what the competition (Tidal) is doing. I want to implement this functionality for my app as well. This is done through documenting a user story for the dev team, and this is an example of the user story I might put together having read that article on my competitor (Tidal)’s features.
If I am successful, the dev team reading this post will have a “definition of Done” an outline of sub-tasks or tasks, a user persona(s) that the story applies to, and an idea of how much time this process will take.
Example User Story
- As Nathan – I want to share songs with my friends who use a different streaming service than me. Particularly my friend/family member who is a “Steven” and insists on using a different streaming service than me. I want to be able to share a song through text messaging, or social media with Steven and have them be able to listen to the song on their own streaming service. As Nathan I care about convenience, and I don’t want to be lectured by a Steven about some streaming service I’ve never heard of, or Spotify’s audio quality. I just want the Stevens in my life to enjoy the music I’m sharing. As a “Nathan” I want the conversation to be about the artist and the music, not about the audio quality, app signup process, or any other information. Just the music! As a “Nathan” this process will encourage me to share more music with the “Stevens” in my life, which will increase my time spent in the app.
- As a product manager/product owner at Spotify, I want metrics on who our users are sharing music with outside of our streaming service. I want to know what percentage of users Nathan is sharing with Steven, or other services such as Apple Music users, Youtube Music users, Amazon Music users and “no service” users who will just listen to the song on the free (low quality + ads) tier of Spotify.
How We Know We’re Done
After reading this user story, we now have our goals, and we’ll know we’re “done” when the following is done:
- Users can share songs on Spotify with users who don’t use Spotify.
- We can collect analytics on the non-Spotify streaming services our Spotify users are sharing songs with.
Example Task List
- Evaluate micro-services that can add this feature (such as feature.fm)
- This needs to be evaluated for monetary cost, and time cost.
- The micro service needs to be evaluated for compatibility with our analytics capabilities (What format is the data available in, does the API give us everything we need, is there a cost or limit to our queries, etc.)
- Design user interface for the updated share button.
- Implement logic to invoke the external API when the share button is tapped.
- Integrate the selected external API into the app’s codebase.
- Develop error handling for cases where the API request fails.
- Test the share functionality on various devices and screen sizes.
- Implement any necessary user authentication or authorization mechanisms required by the API.
- Update app documentation to include information about the new share functionality.
- Optimize the share button for performance and reliability.
- Conduct user acceptance testing to ensure the share functionality meets user expectations (Potentially an A/B test).
- Obtain necessary legal permissions and comply with any data protection regulations related to sharing content with the API.