[codingdave]

Personally, I run a Kanban board for product planning - the end of my board feeds into the beginning of the dev board, with the devs accepting the work onto their board so that if I missed anything or they need more info, it stays with me until it is complete enough that they can work it without questions. This speeds things up because I am not constantly just putting out fires due to poorly written cards.

I also find that product people tend to forget our purpose. PM 101: We say "what" needs done, Engineers say "how". So that is exactly what I write up. I don't diagram technical details, even though I also am an engineer and could do so... but I do get very tight on details of "what" should happen - "Click button a, do thing b, expect UI change c, etc." Cards typically outline a set of actions like that to comprise a feature, and I let the devs worry about whether it needs broken down into subtasks and shared amongst themselves or whether one dev will work it all. Again, my job is "what", theirs is "how".

Forgetting the goal of the product role often leads to product people who spend all their time in meetings micromanaging the dev process, instead of letting the engineers run free to do what they do. Which in turn leads to devs who complain about product people, and the whole team's morale tanks. If you can escape all that, the devs have autonomy to do their jobs and you have time to write good specs while keeping a lightweight process.

Edit: I should add that I don't set my specs in stone - devs are welcome to come to me and say, "Wouldn't it be better to do it this way?", and if their idea is better, I say yes.

[fumplethumb]

We’ve had some success with similar methods. In addition to the simplicity(it just “plugs into” the existing board), it’s nice to get metrics on the bottlenecks happening on the product side of things. If we can show that it historically takes 2 weeks to refine requirements, we can tighten up our estimates and shine a light on potential problems occurring there. If you only have metrics on the dev work, the more business-minded folks tend to focus improvements only on what they can measure.

I’ve also found that folding product workflows into the Kanban board gives the team more visibility and ownership over that end of the pipeline. We can observe how those items age before it ever gets to the dev team and swarm to fix things as a team earlier in the process.

[softprod]

Thanks for the detailed response. It makes sense that you have a kanban board specifically for product. So you feel like devs do a good job with the “how” once you have a good outline of set of actions?

[robofanatic]

IMO product people should not delve too much in “how” especially in large projects. Your role should be to communicate the requirements as clearly as possible to the engineering team and stay away from the “how” part as much as possible. I totally get the temptation of trying to influence the “how” part especially if your past life was in engineering. If engineers are not able to do the “how” then you need different engineers.

[codingdave]

Yep, I think the devs do a great job. If you can't have that confidence in your devs, as the sibling comment here says, "you need different engineers."

[satvikpendem]

Do you do all of the UX then (since you mentioned clicking on X and seeing Y output)? I've generally seen that the PM talks to the user and gathers the features that the user wants, the they hand it to the designer who thinks through the UX and creates the UI, that is then sent to the engineers to be implemented.

[codingdave]

We have a UX team - they have their own column on the planning board. They do work on features that require new patterns, but I write up cards directly if we already have patterns for the feature. No need to have UX burn effort on yet another field/form in the app just like the existing ones. So there is collaboration on who needs to do what for any given feature, and the board tracks it all.

[abyesilyurt]

How do you take care of timelines? A usual complaint I get from PMs is that, they are doing all the micromanaging because they need to provide some sort of dates to clients or upper management.

Do you maybe ask for an estimate on “what”-tickets?

[codingdave]

I don't take care of timelines. That isn't part of either "what" or "how". It is a whole different question of "when". I push back hard on even asking that question.

What I do instead is focus on priority. If the leadership thinks they need a date, I ask why. Often it ties to KPIs they need to hit, or promises they made up the chain, or sometimes even something real like: "We're out of funding in 4 months.". But once I know "why", I can tailor the "what" to focus tightly on that "why", and deliver. If they push for hard dates, then we're back into micromanagement to get the scope to hit the date, and we are wasting time again. So I don't measure effort... at all. I just let the team know what is most important, and we do the work.

The trick is to get leadership to trust that this works. Most of them are used to timelines, scrum cadences, 6 month roadmaps, etc. And if that works for them, great. But it isn't what I recommend for building an effective team who can deliver quickly while enjoying the work.

Edit: I always think of one more thing after I type up a comment... I can succeed in this scenario because I used to be an engineer. I know if something takes an hour vs. a day/week/month and can break things out accordingly. If a product person really does not have that sense, they'll need to ask about effort... but it can be at that high level of hour/week/day/month.