Guidance requested. PM needs some support

Just started in the PM role about 9 months ago. Fast forward and I’ve come to realize there is nothing in place at the company I work for… Meaning no structure, no docs, no process, no user stories, nothing.

During my time I’ve been reading books and taking courses recommend by friends and colleagues.

Anyway, my manager has actually agreed on having me put a prd template together for the team since I keep asking why and how, they’ve finally admitted they don’t have a process.

Little background:

  • Company creates hardware electronics
  • Believe they run waterfall, but they throw out terms associated with agile
  • We sell to integration firms, but our real customers are end users, yet everyone is afraid the integrator will flip out if they find out we are talking to users.

Can you take a look at the PRD template I’ve mushed together from various online and book material? Or if it’s complete garbage, recommend one?

Thanks in advance.


I think it looks awesome. To be fair, I’m only an aspiring PM myself, but from the knowledge that I’ve gleaned from scouring different PM books, I really enjoy the amount of detail you put into this doc. It seems that the most important organs of a PRD are placed in the correct locations. The only thing that I would recommend at this point would be to perhaps adjust the font of the doc to be slightly more professional in the future. I love the spunky feel that the doc currently has, but as your company grows, the sleeker look may benefit the company image. Great job!


@JuanAllo, Thank you! I appreciate your raw feedback and I totally agree… But you have to add some spice.


This looks like a pretty standard requirements doc like ones I’ve seen punted around. Requirements docs, though, make a ton of assumptions from the get-go that feel way more waterfall than agile. Bold of any of us to assume an outcome before we have even broken ground. Perhaps focus the document more on the problem you are trying to solve and why you are trying to solve it and give some space to your team to discover how it should be solved.


From what I viewed, the doc is focused on user stories, users and defining the problem. Ignore the table of contents and go into the document.


Thanks @BethanyGrey, I tend to read through things before commenting. I am specifically talking about how it has sections about design layout, release dates, notes about “technical overview” and “physical architecture” which, I get, why people want to have before they break ground on a project - but I am saying the document should focus on problem to be solved and the why’s. I am not saying that it doesn’t have those sections. These types of documents tend to lean towards waterfall, and one should be careful of that.


Thank you and that’s fair. Release date-found it’s nice to least put a place holder since many do not have a realistic concept of time. Also separated this into 2 phases which should help refocus the approach.


@HeatherKurtz, Release dates are hard! Unless you have a really tight capacity / velocity planning with a dev team that is fantastic at estimating as well as keeping themselves to said estimates AS WELL a stable product that doesn’t have a lot of unforeseen regression issues… :upside_down_face:


Word to the wise: make it public or give out your name. It’s impolite to request anonymity while taking others’ here.


Just save the doc as a copy if you want it. Anyone can view and make comments on the doc OP shared. @HeatherKurtz, Thanks for the template. It’s really very helpful and can come handy to all the aspiring PMs.


Hey Thanks. Feel free to comment on the template! I know this is a learning experience for all of us.

1 Like

+1 though she is a newb, I give her credit for wanting to make change :wink: