# A product management blueprint

DevFeed: [A product management blueprint](<https://devfeed.tech/articles/a-product-management-blueprint-41175.md>)

Original publisher: [Read original article](<https://www.craigkerstiens.com/2015/02/18/A-product-management-blueprint/>)

Author: Map

Published: 2015-02-18T20:55:56Z

Content type: opinion

Language: en

Sources: [Craig Kerstiens](<https://devfeed.tech/sources/craig-kerstiens.md>)

Topics: [Product Management](<https://devfeed.tech/topics/product-management.md>), [.NET](<https://devfeed.tech/topics/net.md>)

Tags: [delivery](<https://devfeed.tech/tags/delivery.md>), [engineering](<https://devfeed.tech/tags/engineering.md>), [focus](<https://devfeed.tech/tags/focus.md>), [opinion](<https://devfeed.tech/tags/opinion.md>), [product-management](<https://devfeed.tech/tags/product-management.md>), [projects](<https://devfeed.tech/tags/projects.md>), [startups](<https://devfeed.tech/tags/startups.md>), [teams](<https://devfeed.tech/tags/teams.md>), [trust](<https://devfeed.tech/tags/trust.md>), [velocity](<https://devfeed.tech/tags/velocity.md>)

## AI overview

The author presents a product management blueprint for startups and new teams, centered on building trust with teammates, improving shipping velocity, delivering iteratively, reducing scope, and eventually prioritizing work that has meaningful impact.

## Source excerpt

I find myself having more conversations with startups - both small and large - about product management. I've blogged about some of the tools in my chest here but I haven't talked much about my "blueprint" for product management, which I find myself laying out in many conversations over coffee. What follows is this process I've used a few times over with new teams to get product and engineering moving together, shipping in a predictable manner, and tackling bigger and more strategic projects. Trust I need to know how to work with my team, what their working styles are, and how we interact. This starts by simply interacting - specifically, outside of the office. I heard a similar opinion recently from Chris Fry (who ran engineering at Salesforce and Twitter) when he remarked something to the effect of: "you can tell a good PM from a bad one based on if he goes to drinks with his team." Without getting hung up on whether it's beers or coffee, it's more about socialization with your team and time outside the office. My personal approach: expect a dinner invite over to my place when I take on running product for a new team. Velocity Once you've started to build some rapport, it's time to get down to business. If being able to quickly commit and ship something isn't a problem for you, then it's easy to just assume this is working. In reality most teams I encounter that need PM support don't have shipping nailed down. You probably already know if you fall into that category of feeling like you can commit and ship vs. not, so if you're not able to do that a few tips: There's some projects that everyone wants to ship that's been tried over and over, don't tackle that first. Shipping something is better than nothing. It doesn't have to be the right thing. Sometimes you don't have to ship something to get velocity, you can launch things you already have Kill scope Test things earlier and more iteratively, the more you can validate or try something without requiring a large in