I am a product manager for a startup in its early stages. Product management, engineering management, UI/UX design, product owner, etc. are among my responsibilities; I am also responsible for 3 customer-facing products (everything is now at the MVP stage), as well as internal tools.
I have now been informed that I must establish a proper procedure.
I’m writing user stories, conducting user interviews, creating PRDs, giving engineers assignments, etc.
However, I’ve been notified that as of right now, I’ve only added 20% of the process, and despite this, 80% of it isn’t up to par with their expectations. I would really appreciate any advice, articles, or experiences addressing how to put up a proper procedure that unites all the stakeholders.
This is not an issue with product management. Understanding what your manager expects from you is the difficulty.
The product management position involves multiple hats, particularly in startups. Furthermore, it’s possible that the person you report to has little to no formal product management experience. For all we know, they might be anticipating that you’ll prepare coffee for the development team.
Go discuss what the other 80% is with them. What do they anticipate? What can I do to improve? Some of it might not be normal PM work. To get the organization to recognize the true value a PM offers to the team, you might need to educate and influence higher up. In a bigger organization, you might also need to perform tasks that other PMs don’t. Ultimately, the decision to perform that labor is yours to make.
Putting your roles and responsibilities in paper and promoting regular formal assessments against those standards are additional effective strategies. You don’t want a manager whose expectations are unclear and whose judgement of you is skewed by a variety of things that are unimportant to the role at hand.
Refer to Andy Grove’s High Output Management for more information on reviews and rubrics.
Best of luck!
Yes, you have 20% of the process documented. This is quite an extensive area with lots of things to know, which comes with experience. Your stakeholders may have this additional experience that you are going to learn.
Let me quickly provide you with the additional steps in industry standard lingo (in bold) that you can Google to learn more. This list is not exhaustive, so maybe others can help fill in the blanks … but should give you an “idea” of the end-to-end software development life cycle (SDLC).
Upstream Marketing (aka Discoveries)
- Business Case
Net Present Value (NPV) or Return on Invest (ROI)
- Project Plan
- Project Plan Approval
- Product Requirements
- User Stories
- Acceptance Criteria
- Daily Scrums
- Backlog Grooming
- Sprint Planning
Design Input Review
- Architecture Design
- Detailed Design
Design Output Review
- Code Review
- Release Candidate Build
- Unit Testing
- Verification Testing
- Validation Testing
- Performance Testing
- Stress Testing
- Security Testing
- Compatibility Testing
- Upgrade Testing
- Development Report
User Manual Create/Update
Installation Manual Create/Update
- Release Notes
- Design Transfer
- Release Candidate Approval
- Product Training
Product Transfer to Operations
- Marketing Announcement
- Notify Customers
- Plan Upgrade/Deployment
- Schedule Upgrade/Deployment
- Deploy to Production
- Handling product issues or complaints
- Tracking issues
- Issues review and risk assessment
- Issues prioritization
- Issues > Product Backlog
This whole list covers the SDLC, plus the pre- and post-SDLC steps. It is a big area that his usually handled by multiple people. It’s good to understand, but you cannot do all of this by yourself. However, you can define some of the processes in these areas.
@AnushkaGarg, Thank you so much, this has been very helpful.
Just to add: if just you as a product manager, follow somewhat a SCRUM process would be enough for you.
Managing of engineering and production is a big task
For the product. market analysis, a roadmap, agile epics and stories, and meetings to reflect on each big public feature release. Select one or two issues from the retro to be fixed during the following release cycle. Your organisation isn’t developed enough or staffed adequately to handle extra rules.
Find three to four procedures or rules (such as code reviews) on the development side that are similar in scope. That is up to you and them because I’m not a dev.
Only later, after you have divided the Dev and PM manager positions and recruited personnel, should you add more process to your lives.
Get something out there right away that people will buy.
Agreed @Nathanendicott. He is wearing 2 VERY BIG hats in his company. Someone commented with a giant list of the end-to-end SDLC process. Really appreciate
Yeah. Ultimately I agree s/he has to consider the whole SDLC. The potential problem I see is, he tells his boss “here are the 100 things we have to do.”
“Great. Do all that or you fail.”
And in his startup, that is precisely what will occur. From here, he can either request a promotion to a director position on the condition that he can employ more personnel to fill some of those functions and expand the organisation, or he can take the other course of action.
All of this is a normal aspect of starting a business and scaling an organisation. There is nothing wrong with this, but, as you say, expectations must be set. If his stakeholders have the necessary expertise, they need to already be in agreement and share the same viewpoints.
Although I wish his stakeholders knew what they were doing, I’ve been proven wrong far too often to believe that they do.
Your advice was very valuable @MariaWilson. I also need to think about setting up an SDLC process.
All of the stakeholders were BD employees or consultants in their former employment; none of them presently have formal product experience.
I must therefore turn to external resources for assistance. And for that reason, there is a lack of expectation clarity.
I completely agree. The challenge is how to manage this conversation with his boss and the CEO/other management. Startups are so fun. But the lack of staff is challenging.
Reporting? From a manager’s perspective, that’s the only thing I could imagine you’re lacking is, but that doesn’t account for 80%.
Could you define early in terms of revenue for “3 customer facing products for early stage startup” as well? Although your definition of leadership may be very different from mine, it sounds like there is a lack of focus and/or product vision.
Whoever said that 80% is lacking ask him for the expectations. Understand what they want and then plan and work on it.
And for the process also I’d suggest you to keep interviews and ask how everyone want things to work around.
One pro tip: don’t put too much of process at once, or you’ll become the main villain. And make sure CEO or whoever is asking you to, don’t make you the bad guy and he’ll play good guy.
I think you’ll need to set up a software development lifecycle, which would cover everything from user interviews through the actual product execution. As a result, this process also comprises gathering requirements, backlog grooming and refinement, development, quality assurance, user acceptability testing, defect correction, and implementation (deploying code into a live environment), as well as rollback and backup procedures in case something goes wrong. Although each of the items I’ve listed has specific areas within each phase, this should give the product team a head start in the process.
As a product manager, it can be challenging to set up a proper process, especially in an early-stage startup where everything is in flux. However, having a well-defined process is crucial for aligning stakeholders, ensuring quality products, and streamlining development efforts.
Here are some tips that can help you in setting up a proper process:
- Define the product vision and roadmap: Before diving into the specifics, it’s important to have a clear understanding of the product vision and the long-term goals. This will help you to prioritize features, define the scope, and allocate resources accordingly.
- Create a product backlog: Once you have a product vision, create a product backlog that lists all the features and requirements that need to be implemented. Prioritize the backlog based on the value that each feature will provide to the users.
- Conduct regular user research: Regular user research is essential for understanding the users’ needs, pain points, and preferences. This will help you to make data-driven decisions and ensure that the product is aligned with the users’ requirements.
- Create user stories: User stories are a concise and precise way of communicating user requirements to the development team. Create user stories that are easy to understand and include all the relevant information such as user persona, use case, and acceptance criteria.
- Use agile methodologies: Agile methodologies such as Scrum or Kanban can help you to manage the product development process efficiently. These methodologies provide a framework for prioritizing tasks, managing sprints, and conducting regular reviews.
- Define the roles and responsibilities: Define the roles and responsibilities of all the stakeholders involved in the product development process. This will help to avoid confusion, ensure accountability, and streamline the development efforts.
- Use project management tools: Use project management tools such as JIRA, Trello, or Asana to manage the product development process. These tools provide a centralized platform for managing tasks, tracking progress, and communicating with the team.
- Conduct regular reviews: Conduct regular reviews with the team and stakeholders to evaluate the progress and identify any issues. This will help to ensure that the product development process is on track and aligned with the stakeholders’ expectations.
To sum it up, setting up a proper process requires a clear understanding of the product vision, user requirements, and stakeholder expectations. By following the tips mentioned above and continuously iterating and improving the process, you can ensure that the product development process is efficient, effective, and aligned with the stakeholders’ expectations.
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.