Product development is an art that leverages many sciences. I’ve experienced waterfall project management as well as various flavors of Agile and have had the best results from SCRUM. Although, I’m not dogmatic about the particulars of the approach, but do believe a few critical strategies need to be embraced and contextualized by an organization to maximize velocity, while ensuring product-market-fit:
- Be with the customer
- Embrace a short-cycle rhythm
- Onboard non-technical staff to the flow
- Minimize context switching
My Ideal Process
To further elaborate on this, I’ve come across this wonderfully concise and useful SCRUM Reference PDF(from Collab.net).
Gravitational Pulls of Product
At any given time the product manager Will feel the gravitational pull of the following three stakeholders:
- Customer/End-user— new features, bugs, etc
- Business model— tools to better manage/process leads, make money, and or onboard customers.
- Platform— technical debt, dev ops, technology modernization, etc
A great product manager understands the importance of clarify what's being asked from these three pulls as well as on boarding the rest of the team to the rationale in trade-offs of why certain things are not being prioritized any given sprint. Likewise, a great product manager will earn the trust of those respective stakeholders by, at the right time, prioritizing stories/Epics for that respective group. Overtime, the groups trust the product manager and become more willing to delay implementation at any given time due to that trust with the understanding these competing interests are being managed with the best intentions.
Related Link: Teachers as Product Managers via p21.org
The Product Management Triangle
In creating and managing a product, the product management triangle has been a helpful metaphor in getting buy-in from other stakeholders to the agile process as well as just a helpful frame of mind for general product management.
Scope is the easiest to get out of control and the easiest to manage when the other two constraints ebb and flow. I've found that the most insidious scope creeps are those that aim for a 'perfect architecture' or are related to well intentioned, but oversized scaling efforts (e.g.- build for 100 million, when max possible is 1 thousand). The second place scope cream often sneaks up is when new end user workflows are perfected outside of real use. I like to call this the Ph.D. problem. Big and theoretical great ideas can quickly bloat and then land with a dud when not enough raw outside prospective from the more intended end user. The general arc of that idea may not be wrong, but the details in the functionality very often prioritize differently than what was conceived from the conference room kickoff meeting.
My experience has been that there is delayed acceleration often under appreciated when attempting to manage the triangle by adding people.
- 1-3 weeks: You first need to find candidates or a consulting partner.
- 1-3 weeks: Next you screen and interview (even with a recruiter this takes time).
- 1-2 weeks: Craft an offer/agreement, ideally do a test project together.
- 1-2 weeks: Candidate to decide.
- 2-3 weeks: Candidate gives notice if already employed.
- 3-8 weeks: Ramp up and contextualization
This timeline is pretty optimistic since it assumes no HR, but I also recognize in a larger company, there may the HR dept could mitigate some of this effort. Regardless, in this scenario, it's 2 - 5 months before a new development hire is ramped up.
If you're ramping up multiple teams at once, this can be tricky as you want to build up capacity and culture to ensure good dev ops and maximize consistent coding. My point is even when the budget can be significantly increased to manage the triangle, the impact is not as immediately leveraged as managing scope and schedule.