How to pull a super tight goal with quality (a usecase)

Possibly a short post. Wanted to get few points out there. I recently shipped something that I’m proud of and thought some of metal framework that I developed worked well. Though, it was not thought out intentionally — it was repeatable what I learned.

There is lot of literature and guidance out there on how to manage people, process and technology. Time, quality, scope and resources is a classic riddle that most project, product and program manager tweak based on situation. A lot depends on the product life-cycle phase, capabilities of the team and what your current situation in terms of technology stack allows you to do.

Few points I am talking about are constrained to —

a) You know your ultimate hit date so you can work backwards.

b) You know what are table stakes for your feature / deliverable.

c) You know that quantity of resources is not substitute for quality and knowledge of team members.

d) This is getting feature out and not building a technology or research problem.

In my opinion, following are the basics that must be deliberately checked off:

1. Most critical thing is a shared goal and clarity about it. There is no way you can get your deliverable out if this is absent.

2. Trust in the team members. It makes sense to make pods and arrange team to achieve this.

3. PMs and execs should absolutely be ever-ready on removing blockers and again, team trusts them.

Here is what works—

1. Something lightweight — like scrum but daily followup with few consistent members showing up that are responsible of their area.

2. One source of truth for functionality — Multiple documents with lots of cross links that talks about //TODOs is a good recipe for disaster.

3. A hub and spoke model in terms of technical components — Des Traynor’s cup cake theory comes to mind.

4. Constant eye on the time left and work left — This is other than your tasks breakdown. Its more from ability to finish the use cases.

5. Focus on usecases (vertical) and not on individual components.

6. You are highly likely to create technical debt — minimize it by making right decisions

7. Say “NO” to new shiny things that will come in your way

8. Lastly- but super critical — involve legal, privacy and marketing folks from hour 0. Its super important link in the chain.

What doesn’t work —

1. Brainstorm design meeting with more than 4 people in room — avoid.

2. Not relevant people being asked / participating in decision making.

3. Designing for 5 years roadmap and getting eyes of the immediate deliverable.

4. Patching gaps for resources from other initiatives. Arguably folks from your project will spend more time bringing them upto speed.

5. Introducing new technology at 11th hour adding more unknowns in the mix

6. Ignoring signals from team-members that they are blocked. Not everyone is vocal. Not everyone is able to anticipate that current trajectory wont make it.

7. Parallel executions of plan B is current track doesnt work. (Though I’ve been guilty of proposing this sometimes myself)

8. Leading team members loosing track of

I hope of some of this will help to someone who is looking for some quick pointers

Leave a Reply

Your email address will not be published. Required fields are marked *