My Product Development Process

As CTO/CPO/Product Owner in Growing Your Startup Tech Product Team, what process do I use?

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

Use Lean Canvas page to document Business Model.

How settle priorities and get input?

  • Product Owner as Onsite Customer need loads of real customer direct exposure: go on sales calls, go on post-sale support calls, but mostly interviews that are neither (Customer Development).
    • Categorizing each interviewee by Persona helps bring some coherence-clusters to the noise.
  • 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
  • focus on the current BottleNeck in the Business Model, consider rough Cost of Delay
  • 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.

Web Design?

  • Try to build a Responsive Web app before making a Mobile app. (Step2: PhoneGap.)
  • 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.

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: |

blog comments powered by Disqus