If you take a look at my LinkedIn profile, you'll see that I've been a little bit of everywhere. While the processes that are out in the wild are all great, my observation is that process is not an easy thing to implement, let alone enforce or adhere to, and no two places are the same with respect to process. There are many variables that affect said processes like timelines, resources, requirements and balance of power. Process will suffer at the deficit of one of these factors.

If you're in a place where you can enforce and adhere to process, that is freaking awesome. Congrats. The reality of the teams I've been in have had a constant struggle with process, and unless you have an entire team committed to bettering how you work together, you're going to have some fly-by-the-seat-of-your-pants level of action—which isn't necessarily a bad thing.

This post is more for you than those of us that have process buttoned-down.

The truth of the matter is that process should be grown organically. The latest and hottest article on Medium is not going to fix your process. That's up to you and your team to commit to.

Fun fact: I know this guy who wrote a book and charges companies for a class that he teaches on product design process, and has yet to be employed as part of a product design team. Jussayin'. Talking heads are a mutha (sometimes)

We all know the prescribed process, and I acknowledge the advantages of said process because they were conceived out of many years of great experience—I'm not about to disrespect the architects. But, if you're in a small startup, or you're in an organization that has a few stray ducks that aren't in a row, here's an idea.

Keep it simple.

The core/common pieces of the process are:

Definition - what is it that we're doing?
Ideation - I think this does the trick
Refinement - no, okay, this does the trick
Shepherding - the typeahead doesn't work right, do this instead

No matter where I've landed, this is the general process, but the differences lie in available personnel ("We don't have a research team? So I gotta do all the research myself?"), timelines and requirements ("Yeah, we said we're an agile shop, but head honcho said to make this exact thing happen by Friday"), and balance of power ("Dude, why you being so prescriptive?").

All that extra process stuff is gravy. As long as you've got your core process solid, you can plug these extra process steps as your team grows or team culture evolves, but plugging in these other steps have to happen where they make sense, and when it makes sense to add them. It's a much kinder approach than to force a heavily detailed PRD on a PM who is effective and works really well with their UX designer(s) and Engineer(s). Also much more humane than wrenching in a deep research requirements for a feature that already exists. Sometimes collecting usage data is just what your feature needs.

If we treated the extra steps (deep research, competitive analysis, PRD, etc.) as tools in our toolbox, we can summon these tools when and where we can benefit from their use the most, as it fits in your team's work style.

Just my 2 cents on the matter. This is not gospel.