As our team continues to grow, we have pain around written requirements for our development team. In my previous roles, I would have called this person a “Business Analyst”. Where does this responsibility lie in the ever-changing spectrum of jobs in a Product team?Understand the Use Cases Understand current product state Work with UX to combine the written and the visual into a cohesive package Document written requirements Maintain requirements as they change Work with QA to ensure everything is current and functioning as expected Keep Release Notes

Solved

What role writes requirements in your company?

11 months ago
24 August 2021
7 replies
194 views

Userlevel 4

gavin
Collaborator
29 replies

As our team continues to grow, we have pain around written requirements for our development team. In my previous roles, I would have called this person a “Business Analyst”. Where does this responsibility lie in the ever-changing spectrum of jobs in a Product team?

Understand the Use Cases
Understand current product state
Work with UX to combine the written and the visual into a cohesive package
Document written requirements
Maintain requirements as they change
Work with QA to ensure everything is current and functioning as expected
Keep Release Notes

icon

Best answer by david.morgan 7 September 2021, 15:10

View original

This topic is closed for comments.

7 replies

In my understanding everybody is welcome to write requirements. As long as you are in the context of the problem space and have an understanding on how to write requirements then just do it. The less people are between the writer and the development team, the better. Agile mindset and evolving business agility might help in your company culture. Our main roles that create and write requirements are:

Product Manager
Product Owner
Business Analyst
Enterprise and/or Solution Architect
UX Designer

Our challenge is that also roles like a Client Account Manager or Supporter is able to write as solid as possible or collaborate effectively with above roles to reduce missunderstandings and effort.

Userlevel 4

gavin
Author
Collaborator
29 replies
11 months ago
25 August 2021

@Stefan Kueffer thanks for the reply!

I don’t have a culture problem to solve, it’s great here! I have a staffing problem. We’re rapidly approaching a point where the people who have agency to contribute to requirements don’t have the capacity in their schedules to do so at a rate that meets our needs. We’re going to adjust the team structure to have a person who protects their time and helps prioritize ‘enough’ requirements to keep dev running smoothly. It’s definitely a collaborative effort from all teams.

I think we’ll probably add an Associate Product Manager as that should provide the right career path as we continue to grow.

Hi @gavin
We here at Wallbox had a dedicated team called Concept Engineers who supported Product Owners defining the functional/complex part of new functionalities and also documenting them in collaboration with UI/ designers, tech lead and QA. This name is invented thus having low recogniotion in the market so I really reacommend you selecting a name as “associate product manager” as it clerly defines the carrer path and puts the employee in a recognisied rol in the market.

However, recently at Wallbox we have reduced the hierarchy levels and put more PO in the frontline of product ideation so: there are more PO with a reduced scope in the product they deal with but with a broather span of project management within the product. We will see how the new reorganization improves performance. Thus, now the so called Concept Engineers will deal only with the big complex projects (more like a specialised internal consultancy) that PO don’t have time to deal with.

Hope this insipires you :)

@gavin another perspective to consider is that it may be time to split the team into 2 separate teams to increase your volume not by speed but by increasing your capacity per cadence/time box. The more specialist roles added decreases the shared understanding your team will have and increases the handover failure rate. It’s better to keep teams small and add more teams.

Userlevel 6

+11

david.morgan
Product Makers Ambassador
157 replies
11 months ago
7 September 2021
Answer

It’s a little tricky, isn’t it? I’m currently the “product team of one” but have opened the floor for our development team to write requirements. However, this means that I’m the one that tends to validate all non-technical requirements to ensure that they match user expectations, demands from the market, and “curate” them in a way that works for the product.

Understanding use-cases is often something that is extended to all employees. I’m the “go-to” for explaining and validating them; however, it also means that each team member has grown to understand the need for certain functionality within the product (and that I’m always open to share product knowledge!).

Release Notes are complicated. Yes, it’s the product/product development team’s responsibility. I am currently looking for a solid Tech Writer to fill this void (having one heck of a time filling this role, unfortunately). This is more so due to the fact that there is always content to be created in a software company (written or otherwise).

At the end of the day, each of the responsibilities you’ve outlined can be broken out into a Product Manager’s daily role (for each product/product enhancement they’re working on). Some can be divided into a separate role (Customer Experience/Business Analyst/Technical Writer). Fundamentally, it’s down to how you want to scale and how well tasks are being managed throughout the team.

Userlevel 4

gavin
Author
Collaborator
29 replies
11 months ago
14 September 2021

As expected, the real answer is “it depends”. Like @david.morgan, I’m a team of one just trying to allow others to do their best work. I think I’m going to open a role for an Associate PM and go from there. I think a technical writer would also help us quite a bit as well in other areas.

It’s fun finding ways to distribute the knowledge and empathy across a small company in different time zones and locations.

Userlevel 6

+11

david.morgan
Product Makers Ambassador
157 replies
11 months ago
14 September 2021

It’s fun finding ways to distribute the knowledge and empathy across a small company in different time zones and locations.

Exactly! :grinning:

When it comes down to it, a product team will always share some dynamics and/or frameworks but there’s always minor tweaks/adjustments for all of us to make our team more valuable/useful to our organization. For me, I’m handling the day to day Product Management stuff fairly consistently/without issues. However, I spotted a weakness in the armor: documentation. So that’s what I’m hiring for at the moment. An Associate PM would definitely help with some of the tasks if the “cup doth runneth over” in ways that impacts the product and efficiency.