You’re reading Sweat the Product. Collections of untold stories from entrepreneurs and product people.

#

Jake Przespo

Product Designer

Interview by Spencer Fry on August 21, 2014

Jake Przespo is a twenty-six year old Product Designer living in Greenpoint, Brooklyn. He now works at a small product studio after having worked at Skillshare for two years as their first employee. This is Jake’s first ever interview, so we sipped on Negronis at my East Village apartment to lighten the mood. Jake talks about his days at Skillshare, their product design process, and the differences that emerge as a team grows in size, explaining how product design is different when you're working at a small studio.

# Photograph by Chris Oakley
Sweat the Product

Can you tell me a bit about who you are and how you came to New York City?

Jake Przespo

Yeah, my name's Jake. I'm a Product Designer. I'm originally from Upstate New York. I was always creative growing up and my grandmother actually taught me how to draw. And that really kind of got me interested in creativity, art and design. Then growing up I just drew a lot. I got a computer when I was very young, I think around four or five, and my mom, luckily, knew that technology was going to be important.

So then my creativity kind of went online and I'm the type of person that just tinkers, so I end up breaking everything. Eventually I stole a copy of Photoshop and took my skills of drawing to the screen. Luckily, I knew from an early age I was going to do something that was in design or creativity at least. I always had dreams of being an architect but I'm actually kind of glad I didn't go down that route.

Those early tinkerings in Photoshop ended up with me learning how to code and design my own website. I started getting to the age where I needed an actual career instead of working at a grocery store forever. So I went to school for web development because I thought the tech side of things was going to be a safer career. Also, the jobs in my hometown, in my area near Albany, are mostly focused around engineering and less about design.

I took a job at the New York State Attorney General's office as a front-end engineer and that was my first internship. That eventually ended and I started working at GE in Schenectady doing back-end development. Things like .NET and Oracle database development. During that whole time I was tinkering still on my own and I just forced myself to go into design.

Sweat the Product

You were working at GE and only had a small web presence, so how did Mike Karnjanaprakorn from Skillshare find you? How did that whole process happen?

I did some freelance work for Skillshare in the very early days until Mike kind of offered me a job and I said, “Why not?”
Jake Przespo

I started freelancing on the side very, very part-time, not doing a ton of work, but just trying to find little clients here and there. I originally thought I was going to just do full-time freelance so I incorporated myself as an LLC and tried to find clients in preparation of quitting GE and doing it full-time. That's when Mike emailed me saying he found my work on Dribbble, which during that time wasn't crowded with so many visual designers as it is nowadays. It was a small tightknit group, luckily for me.

We chatted over email for a couple of months. I did some freelance work for Skillshare in the very early days until Mike kind of offered me a job and I said, “Why not?” It was the first time I moved out, moving to one of the largest, most populated cities in the world, doing professional design for the first time. So I was like, let's just dive in and go all the way with it. That's when I moved to New York in 2011.

Sweat the Product

A lot of this was a first time experience for you. How did your small team of three go about building product, coming up with feature ideas and executing them?

Jake Przespo

In the very early days, I think of any real startup, there's not a lot of processes around roadmap, functionality, features and things like that. We have these small meetings where we just come up with a feature we want to try. Because of the small team, there was no need for process. There was no breakdown in communication, so we would immediately sketch it out, see if it made sense and jump right into visual design.

We didn't do wireframes in the early days just because of the tight deadlines we were setting ourselves. Also the amount of traffic we were getting wasn't business critical where we needed to go through in-depth processes.

That's the thing about when you're on a smaller team. There's no breakdown in communication which means you don't need the same level of process that you would need on a larger team.

Sweat the Product

This was basically the first product you really worked on. How did you improve as a Product Designer? What was that process like?

It's hard to say what those specific steps are, but it was a lot of — and I know it's cheesy — a lot of failing.
Jake Przespo

Yeah, that's a tough question. I don't think many people can quickly say what those steps were that they took to get better. But I will say when I was at GE, there were some internal products that we built. Very small ones. I sort of got used to that flow of creating something, iterating and taking feedback from the community. Things like that. So that helped a little bit.

Yeah, I mean, it's hard to say what those specific steps are, but it was a lot of — and I know it's cheesy — a lot of failing. And that's the only way you can really learn. I read tons and tons of articles of things to do right and processes and design techniques and etc., etc. But even if I would try them it didn't necessarily mean it worked in my specific scenario. So, yeah, that's a really hard question to answer.

Sweat the Product

No problem. So as the product team expanded in size, how did things change when you started to add other designers and developers? How did the process change?

Jake Przespo

As a company, those plans to implement more processes were there. But me, as a young naive designer, I just kind of grew up with the company. It became obvious to me where the more people we added, and we tried to stay with a small, lean process that communication would just break down. Things that you said in a meeting that you assumed someone understood or took a note on didn't happen.

As a team grows, you can kind of see that that's how corporations become the way they are and they have all these processes. It's simply because of communication breakdowns. So as the team grew we had to have product planning sessions. We had to have design feedback meetings on a regular basis. We had to annotate all the flows throughout every feature. We had to create in-depth wireframes.

Sweat the Product

Can you take me through a specific feature from idea to execution?

We were using 37signals style flows of what you see, what you do, and what you see next, what you do next.
Jake Przespo

One of the larger projects I worked on at Skillshare was our class creation tool. When our classes became more in-depth with multiple sessions. This was still when Skillshare was local classes. Right before we were making the move to online. The class creation tool was a way for a teacher to create a class with as many sessions as they wanted to and all the details that came along with that.

In the beginning we reviewed our current class creation tool. We generally knew all the problems with it based on the trickling feedback that came in from the community. But we also did an internal review by looking at the problems that we thought we had too. Then we added to that list the new features that had to exist that we were trying to align with our goals.

There were new features that also had to go along with the old things we had to fix to turn it into a new product within Skillshare. So we usually start with a goals document. We would list out the goals we had for this feature, the metrics we planned to hit, all the features that need to exist in this, and all of the elements that go along with that.

That became our assumptions and our goals. Once we had that document, and the product team agreed that we were all aligned on what this feature is, the details came after that. We just started thinking about all the flows throughout that feature and tried to cut those down to be as small as possible. We were using 37signals style flows of what you see, what you do, and what you see next, what you do next.

Once those were small and pared down as much as possible, it was easy to translate those into wireframes and use that as our starting point for creating wireframes. So as far as wireframes go, we would lay out the architecture of every page and every view within that feature. We'd lay out all the interactions and all the states throughout that whole feature. From an outsider looking in it always looks easy and obvious, but when you're in the details there's an insane amount of little things that go into making sure all your states are covered, all your bases are covered.

We would obviously be doing reviews throughout the wireframing process to catch any potential problems or anything that didn't align with our goals. Then once wireframes were done, we were essentially finished with the bulk of the design work and the design strategy. From there we used our style guides and produced as pixel perfect as possible Photoshop UI files. At that point the engineers would start on the wireframes. They had everything they needed to start laying out the new database structure, all the back-end views that needed to be created and what not. Once the UI was finished we would work closely with our front-end engineer to make sure the design came out correct and everything was working properly.

And from there, there was a QA duration where we would reference that original document to make sure everything was hit and all of our flows were correct and all of our states were covered. Once it passed QA it would be live on the site.

Sweat the Product

What would your key takeaways be having worked as a Product Designer at Skillshare for two years?

Jake Przespo

Since Skillshare was my first professional design job; there were a lot of general ones. Just appreciating how complicated products are and understanding that complication so you can plan for it. Things I learned as a whole, I'd say communication is insanely important.

There were too many times where, as a young designer, I would assume a lot of things and assume people kind of understood what I was saying. I now realize how important communication is and the repetition of all that communication.

Also companywide things. A small thing that was super important throughout just everyday building and designing of features were regular kind of stand-up meetings or regular quick meetings. Just as a refresher or an alignment so there were no breakdowns. No one dropped the ball on anything. Everyone knew exactly what they had to do. Those ended up being extremely important.

As far as design goes in the product, I learned that presenting designs was a whole other skill in and of itself. You can't assume it's enough to simply design every state of the feature and just show it to someone and have them navigate through that document. Presenting that design, explaining that story and all the flows to someone is a whole other skill. But I guess that all kind of ladders up. I mean, all those things I just said kind of ladder up to communication. Making sure everyone's on the same page at all time.

Sweat the Product

So you think that product design is first and foremost about communication?

Product design is 100%... is 95% communication.
Jake Przespo

Yeah, 100%. As far as running a product team, and especially a startup, I think there's a lot of time wasted on long meetings and failed processes when there's a lack of communication or a breakdown of communication. The more people are aligned and it's very clear, the faster the process goes. The better the outcome ends up being, always. Yeah, product design is 100%... is 95% communication.

Sweat the Product

Ever since Skillshare, you've been working at a small product studio. How have you changed from a product and design point of view?

Jake Przespo

I think things have changed. I think all the little details along my personal process have kind of sharpened and kind of honed in. Things like how I structure my wireframes, how I lay out my flows, how I present UIs, and how I have conversations with people have all gotten a lot better in general. I've learned a lot of little mistakes along the way to make me better. Obviously there's a lot of things that I'm still trying to figure out.

Sweat the Product

How have things changed from working on one product to working in a product studio?

When you work on one single product, it kind of becomes your life.
Jake Przespo

Yeah, that a really good question. When you work on one single product, it kind of becomes your life. You know everything about it, every little detail about it, every feature, every bug is glaring to you, which is a good and a bad thing. It's good because you're intimate with the product and you know exactly its flaws and its strengths. But at the same time it's a bad thing because you become blind to a lot of what your user sees. Basically because of assumptions.

But working on multiple products, I've always said that I wouldn't ever want to work on multiple products because you don't get that level of intimacy with any one. But I will say it's a lot more fun. I do think there's a larger challenge to it in ways where you don't know all of the upfront research and all the upfront user feedback and a lot of the history. But that kind of makes it more exciting but also a lot more difficult because not all the problems are defined up front. I will say working on multiple products is more challenging, hence ends up being more fun because I'm the type of person that likes getting my ass handed to me once in a while.

Sweat the Product

I think you're a very good role model for young designers to just get out there, get a job, and get better on the job. What kind of advice would you give to young Product Designers?

If you're thinking you're not good enough or you see these other product designers and think, “how could I ever be that good?” They just spent a lot of time doing it.
Jake Przespo

I'd say there are a couple of things. First and foremost, I feel like there's a lot of bullshit in the design community that you have to learn to cut through and navigate. But once you get through that, there's a lot of amazing people in the community that are willing to help and willing to share their thoughts. They want you to succeed as well. So reach out to those people and meet them and learn what they do.

Other things that were successful for me is just a lot of research. So I read a lot of, not necessarily books, but a lot of articles. I try to remember all the mistakes and successes that other people have had and use that to my advantage. So understanding that landscape of product design as much as possible will help you move into it faster.

Lastly, I guess I'd say is — I don't want to be cheesy — everyone can do it. If you're thinking you're not good enough or you see these other product designers and think, “how could I ever be that good?” They just spent a lot of time doing it. I don't think there's any natural born talent in product design. The more work you put in, the more effort you put in and the more time you put in, it definitely pays off.

It also goes without saying that there are dues that have to be paid, unfortunately. I try to skip them or try to get past them as much as possible, but I think that's just the nature of life. No one can trust that you already know what you're doing and you already can figure things out. There are dues you have to pay but the reward is there afterwards. You know? I'm already seeing some of that.

Sweat the Product

Well, that's great. Thanks very much.

Jake Przespo

Cool. Peace.

The End