I've met many web developers over the years and the common theme is that they tend to specialize in a specific aspect of web development. They're either designers, JavaScript coders, server-side experts or perhaps a tiny bit of all of them. Rarely do I meet someone who is incredibly well-versed in the full-stack having an amazing design acumen and being able to take a vision and bring it to life, front to back.

Jonathan Snook is one of those rare breeds and also an influencer in the web development world. His skills have made him a sought after speaker and writer and afforded great opportunities at companies like Yahoo! and Shopify. He's now venturing into product management and we catch up with him to see how that's going and his advice for anyone looking to jump into that role.

Sure thing. My name is Jonathan Snook and I'm a web developer based in Ottawa, Canada. I've been developing on the web since before Netscape hit 1.0. I've had the pleasure of working on hundreds of projects both professionally and personally. I also speak at conferences and put on workshops and have authored or co-authored three books to date, the most recent of which is Scalable and Modular Architecture for CSS (or SMACSS for short). These days, I'm a product manager at Shopify based here in Ottawa.

Opportunity and misunderstanding! Until earlier this year, Shopify never had a product team. I was working on the design team focused on our core product. As a company, we have traditionally had a very egalitarian approach that allowed anybody to work on an idea. Shopify was growing quickly and really needed product ownership to keep the team and product focused. A product team was being assembled. If you're picturing it being like the Justice League, it's just like that.

The role, as it was described to me, sounded much like the work I was doing as a designer. Talk to customers, the support team, and other stakeholders to evaluate which problems we should be solving and testing our work to ensure that we were solving our problems well. This sounded fantastic and I jumped at the opportunity. I misunderstood just how much work it really was to define a solid product direction and be able to communicate that effectively both within the company and out. As a result, I've not done nearly as much hands-on development as I expected I'd be able to continue to do.

Shifting into product management has meant learning new skills. I've been doing a lot of reading. I've been researching what makes a good product manager. I've been researching what needs to happen for a team (or multiple teams, really) to build a good product. It's been a great opportunity for me to grow and has been very exciting.

I'm still coding when I can but not nearly as much as I used to. However, I still read the blogs and twitter posts. I try to stay on top of the industry, and I still get to speak and attend great conferences where I can expand my knowledge. I still participate on pull requests and technical discussions. I still feel like I've "got it", at least from a technical conceptual level. Actually spending a day writing code, on the other hand, might prove a little harder. Just don't tell anybody that!

I've been fortunate to have a well-rounded career having done design, front-end development, and back-end development. One of the advantages to having this breadth of skills is the ability to deeply understand the requirements at all levels. I'd be lost without the ability to understand the design and technical hurdles. I wouldn't be able to engage my co-workers on the same level. They're very smart people that can code circles around me but at least I can understand what they're doing and why they're doing it the way they are. I think this is very helpful.

On the bad side, it's not anything you don't see come out of any team. People have different ideas of what we should be focusing on. Sometimes I don't communicate the vision and direction well enough and that can create confusion and conflict. Those are skills I'm working to improve upon.

At Shopify, we're dealing with a 7 year old codebase. The team often wants to work on refactoring things instead of the shiny new features. I'm the one who wants to implement the new shiny features.

Of course, with all things, balance is key. One of the things that I liked when I worked on the design team at Yahoo! was the regular maintenance cycle that was built into their process. Clean up files, fix naming, get rid of cruft. As Shopify grows, we know we need to continue to keep this balance. I think we're on the right track, even if sometimes we disagree when we should be doing feature development or should be doing refactoring and maintenance.

Even though we had product managers at Yahoo!, I rarely interacted with them. The role was largely foreign to me until I decided to jump in head first.

If you want to be a good product manager for a technology company then I think a well-rounded background is good to have. Then again, I think that for nearly any role you might take. (And I believe that working for a web agency is a great way to gain that experience. Although, I'm probably biased since that is the path I took.) A good product manager needs to be able to communicate well. A good product manager needs to have empathy. At Shopify, for example, I run a store. In fact, I sell my book, SMACSS, on Shopify. This helps me understand some of the problems that our customers face every day. I don't think I could manage a product I didn't believe in.

For those looking to transition from development to product management, having that passion for the product is going to be key. For me, it was an opportunity to have a bigger picture of the entire ecosystem and to have more sway on the direction across the entire system. I wanted this because I want Shopify to be amazing. I want it to be something that people enjoy using every day.

If you want to become a product manager, don't let the word "manager" scare you. Don't worry about losing your skills. The industry changes fast but not that fast. It just feels like it does. If I decide that I want to leave product management and get back into coding full-time, I feel confident that it would be a reasonable easy transition back in. (Then again, it's only been 6 months. We'll see if I think the same thing in 2 years.)

Frameworks don't code your entire site. Take any framework and you still have to add your code on top of it. This was the problem I was trying to solve. What problems are the frameworks trying to solve and how is the code you're writing going to fit in with everything else.

That's why SMACSS is written the way it is: it's not a framework. It's meant to describe a process. It describes a way of architecting a site. It's a documentation of the learning process I went through in building large projects with large teams.

SMACSS came out of real-world development. It's not pie-in-the-sky thinking and it's not a lone wolf approach. It's an amalgamation of many ideas that were already floating around.

As an industry, we've been seeing more and more designers and developers approach site design as a modular system instead of as a series of brochure-style pages that don't change. The modular approach means that parts can be moved around. The more autonomous the parts, the easier it is to move them and add new ones or remove others.

SMACSS, being a scalable and modular architecture for CSS, is catered to the dynamic needs of UI and UX development.

Of course, it's always easier to be able to write everything from scratch but that doesn't always happen. I had that privilege at Yahoo!. But coming into Shopify, I was contributing to an existing project that had already been under development for some time. "If it ain't broke, don't fix it" is a familiar mantra but refactoring should be something that projects make time for. Refactoring removes the technical debt that has built up allowing for faster development for new features. As they say, "there's no time like the present" to begin implementing a modular approach to a project. Just do it one piece at a time. That's the approach we took at Shopify and one we continue to take.

It depends on the process! When I wrote SMACSS, I wanted to present a number of concepts that could be taken in part or as a whole since that's the way I am when it comes to development. I'm unlikely to take someone else's project wholesale. I'm going to take the pieces that work for me and leave the rest.

Have you seen the Twitter client ecosystem?! Yeah, I think I'm okay having let it die. I'm happy with the small success it had (which wasn't really that much to begin with) and enjoyed the process of building the app. Alas, my time was better focused on other projects.

Thank You Jonathan

Jonathan, thank you for taking the time to chat with us and for your great advice on transitioning to product management. If you'd like to learn more about Jonathan be sure to visit his blog and follow him on Twitter. You can also find out more about SMACSS at the project site.