My Product Development Process

As CTO/CPO/Product Manager in Growing Your Startup Tech Product Team, what process do I use? Agile Product Development.

  • 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.

Use Lean Canvas page to document Business Model. That drives your Product Vision and Product Strategy (Strategic Context).

How settle priorities and get input?

  • 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
  • also seek input from internal people in all departments, including my own (devs, customer support, etc.)
    • create/maintain good/honest human relationships with all these people for more trusting Congruent relationships
  • focus on the current BottleNeck in the Business Model, use Opportunity Solution Tree to associate ideas with user Problems, bias action towards the biggest Problems.
  • 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.

Put in Wiki-centric Software Forge. (Hack Your Project Team With An Issue Tracker Wiki)

Web Design? For many but not all apps....

  • 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. (That's become less realistic under React and other javascript-heavy frameworks.)

No Iteration or Sprint heartbeat. Closer to Continuous Delivery, but not quite.

Agile Testing: Test-Last Development.

Reflection, improvement?

  • 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
    • annually
    • after a big deploy
    • whenever things seem off (in a sense this isn't a Retrospective, but a good time to Go Meta)

Edited:    |       |    Search Twitter for discussion