Process Oriented vs. Product Driven

Lately I've been doing a lot of purging of files online and offline. I've tried to be meticulous and make sure I don't get rid of anything I truly want to hold onto and remember. I did stumble upon a snapshot from a book I must have opened in a store somewhere or maybe I found on Twitter. Whatever the source, I am really glad I found it again.

I did some quick searching and found the picture was out of the book, 101 Things I Learned In Architecture School by Matthew Frederick. The excerpt talks about the differences of being process oriented vs. product driven. Here's the quote:

Being Process Oriented, not Product Driven, is the most important and difficult skill for a designer to develop.

1.Seeking to understand a design problem before chasing after solutions;

2.not force-fitting solutions to old problems onto new problems;

3.removing yourself from prideful investment in your projects and being slow to fall in love with your ideas;

4.making design investigations and decisions holistically (that address several aspects of a design problem at once) rather than sequentially (that finalize one aspect of a solution before investigating the next);

5.making design decisions conditionally – that is, with the awareness that they may or may not work out as you continue toward a final solution;

6.knowing when to change and when to stick with previous decisions;

7.accepting as normal the anxiety that comes from not knowing what to do;

8.working fluidly between concept-scale and detail-scale to see how each informs the other;

9.always asking “What if . . . ?” regardless of how satisfied you are with your solution.”

These are great tips that can apply to many aspects of our lives, from projects at work to decisions we make at home. Personally, I am attest that it's easy on work projects to find yourself in a reactive state.


Here's some ways I can apply this list, point-by-point, to my own work (currently game development) and personal projects.

1. Taking time to investigate and research the project, who the audience is intended to be, current trends, and where things might trend by the time you finish

2. Understanding that just because you have a lot of equity in product A or lots of libraries written for a past project, doesn't mean they are the right fit for what you're currently working on. Are you working on a new platform? Maybe the old libraries or methodologies are too cumbersome to onboard help when you need it. You might end up paying for a month's worth of time just to get them ready to actually contribute!

3. Oh man, I'm guilty of this. And I'm kinda glad I am. Part of me feels like a machine if I just resolve myself to show up (being powering up) and perform a task and leave (being powered down). I want my work to be a reflection of who I am as a person - the care I put into things should show that I care about my work and I care about the user's time as well.

4. This gets back to the reactive nature I talked about earlier. It's very easy to do and hard to avoid this on personal projects where it's just you. There are no morning stand-up meetings with your team to hold you to a big picture. Still, this one is easy to do in a team setting to. Racing towards the next deliverable to show feature X might discount the interoperability of X with Y and Z. The pieces have to fit together cohesively, interlocking like a puzzle.

5. I would call this point "Don't Get Too Attached". Things change. Deadlines approach. Scope has to be cut due to time and/or money. Also, the way you're approaching the problem, with good intentions and what you knew when you started solving it, just might not be the right solution. You might find yourself at the end of your task and your solution is inflexible and cumbersome to implement or use. Write down a list of what you learned from the experience, why the solution didn't work, and use this to move forwards more intelligently.

6. The runner-up for the "Don't Get Too Attached" title. While working on Robots Love Ice Cream for two and a half years with my own company, Addo Games, I made the final call on all decisions pertaining to design of the game. That quickly changed when the game changed hands when Addo Games was acquired. There were more stakeholders. I was under the impression I'd still get to make the final call on anything pertaining to the game IP, but that, rather disappointingly, was not the reality.

7. Anxiety. I could talk a ton about it and how much it has consumed me at times. My advice here: Get away from the task at hand and get some fresh air from time to time. Let's say you're toiling late into the night and you're just not making progress. Sometimes even if you have a deadline (self-imposed or not), get some rest. Your physical and mental health is always more important than your work. The best thing you can do against anxiety is lead a healthy lifestyle, eating right and getting plenty of exercise.

8. I was a bit fuzzy on this one as I think the terminology is more directly associated with architecture, but I think Frederick is effectively saying that you have a both a vision (concept) of your design as well as the implementation (detail). When you're in the detail work of the design, sometimes you need to back away and look at the big picture. You might ask yourself, "Am I still on the right track? Is this true to the vision I intended?"

9. Your perspective is uniquely your own. Asking, "What if?" often allows you to see through the eyes of others, at least as you understand others. It also allows you to debate your assumptions. What if this doesn't go as planned? What if this takes too long? What if no one buys this? What if another product comes out at the same time and has more attention?

As you can see, this list goes beyond the reach of Frederick's profession. This is a great list to keep at-hand to help yourself stay grounded in whatever your endeavor may be. I challenge you to make a list of your own of how these points look and are applied in your own life.

Let me know your thoughts in the comments!