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.
• Update: This page sounds inflexible, but it's more of a specific example. In practice, I start from the mindset/principles from Agile Product Development and then adjust to the people/needs of the specific team: Gardening Your Product Process.

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

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

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 Roadmap might be 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. Project-oriented Roadmaps are counter-productive for Software Product Teams.
• 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.

Technical details

latest intent

Inspired by (2022-02-03) Jeffries ExtremeProgramming Thoughts....

Start with a Majestic Monolith, spin off use of cloud-provided (AWS or GCP) services only when you feel sufficient pain.

Keep slicing each story until it takes less than a day. Maybe you just let 1+ devs do some of that splitting on their own.

Track Four Key Metrics, decide whether you need significant improvement in any.

Trunk-based development with feature toggles to control rollout.

Pair programming or mob programming to provide 90% of code review (along with automated tests).

Something approaching CI/CD....

older notes

Story handling

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

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

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

I 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.)

Agile Testing: Test-Last Development.

Other bits

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

• Try to build a Responsive Web app before making a Mobile app. (Step2: React-Native app hosting webviews.)
• 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.
  • v2: That's become less realistic under React and other javascript-heavy frameworks.
  • v3: Figma is making this easier again

Reflection, improvement?

• Gardening Your Product Process
• I have historically been bad about doing One On Ones frequently enough, but I'll do that better in the future. :)
• Occasionally have a team Retrospective
  • after a big deploy
  • whenever things seem off (in a sense this isn't a Retrospective, but a good time to Go Meta)
  • quarterly, if it hasn't happened already because of the previous triggers