Skip to main content

Starting a new product

Last post 02:53 pm August 6, 2018 by Tim M
5 replies
09:17 am August 2, 2018

Hi,

I starting working for a mid size company ( about 50-60 people ) we have different squads looking after different products.

Each squad has a designer / 1-2 dev's / QA / PO and some other shared resources.

I'm the PO for my squad.

Things seem to be done a little differently in this company and wanted to ask about process and responsibility in here.

There is only really 1 stakeholder. There is 1 other in a different office but doesn’t really get involved with day to day things.

We have a new product to get to market – ( it’s a website )

I know a lot about the market and the customers. I’ve been working in this market for about 10 years.  ( not a a PO )

We’ve not had our first meeting about this new product yet, it will be happening in next week.

I’d like to know the following

  1. Who says what this product should look like? is it the stakeholder or the PO?
  2. Who talks about the features they want for the product? is it the stakeholder or the PO?
  3. Do the stakeholder just say something like I want a website that has A/ B / C and hand it off to the PO?

I don’t want to go into this meeting and not know my role or what is expected. I’ve worked as  PO before a about 13 months but this is a lot different.

What I think is this;

The stakeholder will give me an overview of what he wants and what he expects this site to look like and preform.

We discuss possible features and make a list of must haves / nice to have etc. (Should I be giving my input into this list of features? or just listening to what the Stakeholder wants ?)

Then I as the PO go and write up stories / plans / and fully understand how it should work.

Then have meeting with Dev’s and explain things to them and gather questions and go back to stakeholder (If I can’t answer them myself)

Who add’s things to the backlog? I know the PO managers the backlog. But will the stakeholder be adding tickets or will the stakeholder come to me with the item they’d like and then it’s up to me to research it and add to backlog and decide if or when it will be done?

 

Thanks and sorry for all the questions.

 

 


12:55 pm August 2, 2018
  1. Who says what this product should look like? is it the stakeholder or the PO?

Actually, a UX specialist and a BA might also want to chip in... You could call them stakeholders as well, my point is that they might have some knowledge neither you (PO) not the major stakeholder have.

  1. Who talks about the features they want for the product? is it the stakeholder or the PO?

I would say the stakeholder should be able to express what he wants, and then the PO should, together with him, craft a shared vision of the product.

I don’t want to go into this meeting and not know my role or what is expected. I’ve worked as  PO before a about 13 months but this is a lot different.

You should be maximising value of the development team's work to the company. Whether this means strictly following staheolder's requests or not might vary, as you could also identify addidtional stakeholders.

listening to what the Stakeholder wants ?

Is very important, but not "only".

Who add’s things to the backlog? I know the PO managers the backlog. But will the stakeholder be adding tickets or will the stakeholder come to me with the item they’d like and then it’s up to me to research it and add to backlog and decide if or when it will be done?

His requests should ultimatly be going through you.


12:13 am August 3, 2018

>> Who says what this product should look like? is it the stakeholder or the PO?

The Product Owner may work with the stakeholders to understand the needs of the marketplace to determine what will be valuable, and then the Product Owner will figure out what the initial order of features should be.  When I see "looks like" I think of a  visual solution, which I would think the designer on the Development Team would be responsible for.  The designer will design the solution iteratively with feedback from the Product Owner during the Sprint, and at every Sprint Review the stakeholders will inspect the latest product Increment and provide feedback.  Rinse and repeat every Sprint, and start incorporating end user feedback into the Product Backlog,

>> Who talks about the features they want for the product? is it the stakeholder or the PO?

>> Do the stakeholder just say something like I want a website that has A/ B / C and hand it off to the PO?

The stakeholders may convey desired features to the Product Owner, but the Product Owner makes the final decision on what would be most valuable.   The stakeholders may also provide information in the Sprint Review which may end up in Product Backlog adaptation.  As the Scrum Guide states, the organization must respect the Product Owner's decisions, if they want to succeed.

>> Then I as the PO go and write up stories / plans / and fully understand how it should work.

Releasing a "Done" Increment and understanding empirical process control are the two most important concepts to learn, when it comes to Scrum. 

My advice is to start with a vision, and an initial Product Backlog with enough Product Backlog that is "ready" for the Development Team to start Sprinting.  Keep everything else high level.  One of the most important concepts to learn about Scrum is empiricism - that is, make your best decisions based on facts (transparency).  Inspect and adapt what your stakeholders are telling you each Sprint, and if possible, release a "done" Increment as often as you can so you can inspect and adapt what your customers are telling you.  What are you going to measure i terms of value to know if your Product is useful?

Your Product Backlog should be emergent - meaning that every Sprint it changes, adapts, and new items get added and removed as you learn more through empiricism.

>> Who add’s things to the backlog? I know the PO managers the backlog. But will the stakeholder be adding tickets or will the stakeholder come to me with the item they’d like and then it’s up to me to research it and add to backlog and decide if or when it will be done?

You should make your Product Backlog transparent for the stakeholders, and they should be giving feedback so that the Product Backlog adapts, but you the Product Owner are accountable for who adds items to it.  You get the final say, but can delegate the work to the Development Team, do it yourself, or partner with the Development Team.  Typically stakeholders don't add things to the Prodct Backlog directly.


08:43 am August 3, 2018

thanks for the replies. Some really amazing information there.

 

thanks.


10:38 am August 3, 2018

Things seem to be done a little differently in this company and wanted to ask about process and responsibility in here.

Isn’t there a Scrum Master who can advise team members and the organization on such matters? That’s part of the SM role. Where you have questions others will surely have them as well.


02:53 pm August 6, 2018

Lot of pressure, right? So, there are books and websites that can help you.  I’d start thinking lean sort of with the minimum viable mindset. Build, test, learn. I would not depend on just 1 stake holder and yourself to build this website unless you just know what they are looking for. You know the market and your customers you have said but that is not always enough. I think there might be built in assumptions and you could build the wrong thing.

Don’t go down the path of building this in a void. You will need input from others. You, the organization, the stake holder, the customers most important.

“We discuss possible features and make a list of must haves / nice to have etc. (Should I be giving my input into this list of features? or just listening to what the Stakeholder wants ?)” Again, think minimum viable product meaning 1st few sprints you only have to build “just enough”.

This 1st meeting is your kickoff and your 1st chance to figure out what you are building but you will have other meetings.

DO you have a product vision? DO you have a roadmap? What’s the end game for the product.?

I think you should think like a Project Manager and build your scope 1st. You should even come out with your 1st set of PBI’s from this 1st meeting. You have a lot of work to do.

YOU own the product backlog, you prioritize the PBI’s and you decide what PBI’s have the most value for each upcoming sprint. 

You write the stories for the most part, but anyone can write a story. You should read and approve any story before it goes into a backlog.

 

 

 


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.