My Product Development Process
- Note I believe this process requires surprisingly little change to support larger and more-mature software product development environments. Much of what is considered "more-traditional management" is a net-negative in software.
How settle priorities and get input?
- focus on the current BottleNeck in the Business Model, consider rough Cost of Delay - see tweet
- Product Manager as Onsite Customer need loads of real customer direct exposure: Continuous Discovery;
- Categorizing each interviewee by Persona helps bring some coherence-clusters to the noise.
- if high-touch sales process: go on sales calls, go on post-sale support calls
- structure as Opportunity Solution Tree
- also seek input from internal people in all departments, including my own (devs, customer support, etc.)
- create/maintain good human relationships with all these people for more trusting Congruent relationships
- cf Agility Vs Conflict
- doing something like a Road Map is a useful Planning exercise once/year, and you review it occasionally to look for ideas worth pulling into the funnel, but don't let it be a Commitment, or even locked-in list of pre-framed Projects.
- Iterate the Business Model!
Maintain Development Queue listing work to be done.
- The items at the top of the list are pretty precise in what order you expect to do them, they get rougher as you go down the list.
- If User Story is small enough, then just have 1 ticket for all the User Story's tasks; might not even have a separate wiki page for the User Story (sometimes the User Story name is the ticket title, sometimes there's additional text in that title). If User Story is bigger, make an Issue Tracker node for each Engineering Task and a wiki page named for the User Story to help hold them together. (And every VCS commit-comment references Issue Tracker number, and probably User Story name.)
- Sometimes I write a fairly detailed spec, including db changes; other times I just sketch out the problem we're trying to solve, and then work out the details with the developer once they start work.
- Each dev is limited to 1 "big" User Story at a time (WIP /Kanban). When one is deployed, I nudge them toward one of the items near the top of the Development Queue, but they can talk me into giving them a particular one.
- When they need a break from their current big User Story, they can pull any "small" User Story from near the top of the queue themselves to fill time. If a small item is Urgent, I'll tell everyone that that's the next one someone needs to pull.
- Rough (PowerOfTwo with minimum of 0.5 man-day) task-Estimating just to compare cost to value for prioritizing. No Velocity or Burn Chart.
- Try to build a Responsive Web app before making a Mobile app. (Step2: React-Native.)
- Try to use BootStrap as long as possible, unless it's inappropriate for some reason.
- Use contract designers to design themes your developers can extend without help. Make them deliver HTML/CSS/JQuery.
- Heroku or Amazon Elastic Beanstalk hosting, with associated Configuration Management practices. Possibly Docker.
- I prefer a thin Python Web Framework like Flask.
- Use a DVCS, but still use a separate branch for any bundle/cluster of tasks that need to be deployed together.
- Almost never use Pair Programming, though sometimes I'll have people working on inter-related tasks/stories sit with each other to code in parallel while agreeing to interactions in real-time.
- These make good clusters for peer Code Review, though having a separate dev, esp senior, involved at least for a bit, can add value. (I also don't bother with Code Review for small/simple tasks.)
- I have historically been bad about doing One On One-s frequently enough, but I'll do that better in the future. :)
- Occasionally have a team Retrospective
Edited: | Tweet this!