3

I previously headed up a support and training team for a home-grown software product.
I have now moved into a product engineer/specialist role, within same company.

My background has been purely technical.

I want to be as ready as I can to move into this new role.
I have picked out some of the key duties from the job description, and I would like some advice on how I can prepare myself for this role.
e.g. Books, web-resources to read, experienced advice, etc.

  • Act as a product evangelist
  • Assist with onsite delivery of product.
  • Analysing client requirements and developing software specifications based upon these
  • Experience in Iterative (e.g. Scrum) software development models and methodologies
  • Provide support to business development on tender responses
  • Provide business analysis services around product development
  • Develop consistent & high quality product documentation
  • Develop product training materials

I will be reporting directly to the product manager.
1 dev lead, 4 devs, 2 testers, 10 in support, a marketing team and a bunch of people that will go on site to install the product.

Related Q

Let me know if you need more details via Comments and ill edit/re-phrase.

closed as off topic by jmort253 Jul 27 '12 at 19:31

Questions on Project Management Stack Exchange are expected to relate to project management within the scope defined by the community. Consider editing the question or leaving comments for improvement if you believe the question can be reworded to fit within the scope. Read more about reopening questions here. If this question can be reworded to fit the rules in the help center, please edit the question.

  • Questions on PMSE should be about a project management problem. This seems off-topic since it's not about a project management problem. – jmort253 Jul 27 '12 at 19:31
1

Well for a crash course as it were... ManageIT - http://pragprog.com/book/jrpm/manage-it - is a good resource. Though more geared to becoming an IT manager, it has a lot of good basic info.

also PM Crash Course by Rita Mulcahy is a good quick reference for more "pure" pm tasks.

From a Scrum point of view... try to use your Product Manager as the Product Owner to develop the backlog of applications & features. Hopefully they can act as the main decision maker for prioritizing work from a business point of view.

Also get you dev lead and testers involved early on in the requirements and design phases. The testers should be used to create validation tests for what is being designed so you can map requirements to tests, a way of making sure the devs are on the right track in the long run.

That's the initial 2 cents...

1

If your background was on the support and training side of the business I think you are going to be well armed for your new position. I have added a few comments and questions I would ask myself for some of the items you mentioned.

  • Act as a product evangelist ( What is the vision of the product? What is the 6 month goal? What is the 1 year goal? What is the five year plan? Work with the product manager to ensure that you have a clear understanding of these concepts. You can't get somewhere if you don't know where you're going.)
  • Assist with onsite delivery of product. ( Communication & follow up. Is the customer satisfied? How do you measure success? )
  • Analysing client requirements and developing software specifications based upon these ( Build what you need....Not what you think you need. If you find yourself building the wrong feature..STOP. )

I'm assuming you have some knowledge about SCRUM & as you stated I'm making another assumption that it was from the development side of things. If you haven't had much experience writing stories or gathering requirements I would highly recommend reading Mike Cohns User Stories Applied book.

The only other thing that comes to mind is that while documentation is important, it is NOT the most important part of your job. Relish the contact you have with people in your organization, with your customers, with your management team....this interaction is more important than any process or documentation tool you have at your disposal.

Not the answer you're looking for? Browse other questions tagged or ask your own question.