Author: Michelle Chan

An Interview with John Sheehan, CEO and Co-founder of Runscope

rs-logo-color-400x100

My summer at Runscope has been the best internship experience that I’ve had in my three years of college. Runscope provides a suite of API monitoring and testing tools that help developers build better apps and better businesses. When Christiaan from True sent me an email that I would be interviewed by Runscope, I was a bit puzzled—how could I contribute to a dev tools company as a designer? However, once I spoke with John Sheehan, Runscope Co-founder and CEO, and Matthew Ginnard, Principal Designer, I was really moved by their sincerity in not only helping developers grow, but also in helping me grow as a front-end developer. It was the people at Runscope who made me want to work there. Throughout the internship, they have also made me realize how important product design is in creating development tools, which is often distilled from fancy visual elements to pure functional design. Apart from design, I learned a lot from simply experiencing the company culture of Runscope under the great management of John and Co-founder and CTO Frank Stratton.

I recently had the opportunity to ask John more about his life as an entrepreneur, which taught me a lot about being resourceful and the factors that have influenced his practices that make Runscope a great place to work.

About John Sheehan

John is the co-founder and CEO of Runscope with more than 15 years of experience working in various IT infrastructure and tech roles. As an early employee at Twilio, John led the developer evangelism program and managed the Developer Experience. After Twilio, John became Platform Lead at IFTTT (If This Then That), a service that allows users to make conditional actions across different apps like Gmail and Pinterest, and worked closely with API providers to create new channels.

Q: How did you get into technology and entrepreneurship in the first place?

Interest in Software from as Early as Eighth Grade

I started to learn programming in eighth grade after joining a computer club after school. We learned BASIC on old Apple II computers that had a black background with green text. I started by writing a little bit of BASIC, but I didn’t understand any problems that could be solved with programming, except silly games like random number guessers and tic-tac-toe.

Shortly after that, on my birthday, my family and I went to a computer software store where I discovered Visual Basic 3.0. I convinced my parents to buy it for me. When I got home, I couldn’t figure out what to do with it—but what I did figure out was how to make fake error messages pop up in a dialogue box telling you that your computer had crashed. I started uploading this as shareware on CompuServe, the first major commercial online service in the United States that was later acquired by AOL,and would mail people a disk with the shareware on it. The shareware was completely harmless and the free version was called Joke and Prank, but I also made one that I charged people for called Error with 10 or more error messages. I was 14 years old at that time, and although I didn’t get a lot of money, I did get featured in PC Computing Magazine’s 1001 Best Downloads.

Transitioning into Self-Taught Entrepreneurship

After that, I went back to fixing computers because that was what people were mostly willing to pay for. I started attending college, but hated it, so I decided to quit after a semester and start my own company making websites. That was during the dot-com boom, so I figured I could make a bunch of small websites doing various things, but it didn’t go well. I went broke, moved back home, and then tried different jobs like pizza delivery and working for a health club.

When I was 19, I got a job doing website development and computer repair for a company in the Twin Cities (Minnesota). For a few years, I worked at various similar jobs, mostly doing web development. I was working with a lot of sports organizations (Minnesota Vikings, Minnesota Twins, Minnesota State High School League), and that’s when I decided to start another business in 2005 (yes, the third one!) to make software for recreational sports groups to manage their leagues.

When that didn’t take off, I joined another creative agency called Treefort. While I was there, we started a side product called Screenfeed that produced content for digital signage. You can actually see Screenfeed content in the Montgomery Street BART Station in San Francisco today! It was essentially content being delivered via an API. I liked working there, but right around this time I got particularly interested in working with APIs, especially in what Twilio was doing.

From Employee of Twilio and IFTTT to Co-Founder of Runscope

I was getting pretty involved using Twilio’s platform, so when I ran into a few early Twilio employees at a conference, I introduced myself and quickly got a job offer to be its first Developer Evangelist. When I started, there were only about 10 people in the company. For the first year, I worked remotely, based in Minnesota and then Colorado, but I was flying all around the country promoting Twilio to developers at conferences and hackathons. I later became a Product Manager for Developer Experience, making sure the day-to-day tools developers used with the Twilio APIs worked well. After two years with Twilio, I headed to IFTTT where I worked on helping partners integrate their APIs to the IFTTT platform. I found that a lot of these APIs had performance issues that other tools weren’t helping us solve. I got together with Frank Stratton, with whom I worked at Twilio, to build tools to solve those problems, which became Runscope.

It’s been a long road to get to the point where I felt ready to start a company like Runscope. I’ve had a lot of companies in the past, but this is by far the most successful. All of my previous experiences really built up to this, and it’s nice to have found my calling. It’s the one thing that I want to focus on for as long as possible—I want this to be my last job. I want the company to be so successful that none of us have to work anywhere else ever again. That’s my goal.

Q: How was your experience at Twilio and IFTTT?

They were both really great experiences, both really small when I started. At Twilio, there were about 10 people when I started back in 2010. Twilio now has more than 500 employees and has raised over $230 million in funding—it’s worth over a billion dollars. But back when I started, I would have been excited if we were acquired for $10 million. Over the two years I worked there, it grew so quickly that you had no choice but to learn as fast as you could to keep up. There was no opportunity to be lazy or complacent because if you did, the machine would grow past you. Even now, I get impatient when I feel like we’re not moving as fast at Runscope.

It was also interesting to see the progression within Twilio and IFTTT. Twilio was very different when it started at 10, versus 20, versus 50, versus 100+ when I left. There were different challenges at each stage, and being able to watch that progression has helped us prepare for similar changes at Runscope and avoid some of the common pitfalls associated with growth.

Q: How has your experience at Twilio and IFTTT impacted your present work?

There’s probably not a day that goes by that these two companies haven’t influenced how Runscope works. Runscope shares a lot of philosophy with Twilio, which is prioritizing features and products to be focused on developers above all. Our goal as a dev tools company is to help developers become more productive and successful at work.

From the IFTTT side, I took a lot of inspiration from the IFTTT product design. For example, we use a lot of whitespace, and IFTTT uses whitespace probably more than anybody else on the Internet. Trying to keep things simple and distilling everything down to its essence is core to Runscope’s design and is definitely a carry-over from IFTTT.

Q: How is it like to manage Runscope?

When the team was small I didn’t have much of a management strategy. We hired smart, self-directed people and let them do their thing. We still do that, and I mostly just coordinate among all the moving parts. My goal is to distribute as much responsibility as possible so that people can have enough autonomy and authority to be responsible for the outcome of their decisions. I do not want people to fear making mistakes. As a startup we have to try new things and many of them are not going to work.

Everyday I am trying to push decision making and responsibility to other people. I want other people to be as responsible for as much as they are willing to be responsible for. My goal is to get people who can recognize a problem, determine a course of action and implement the solution—even when things might not be very well defined.

Q: What do you see in the future of Runscope and the API economy?

There are a lot of problems left to solve in software development. There will never be perfect software, so as long as we keep coming up with tools that can bring value to developers and the companies they work for, we have a bright future ahead of us.

As for the API economy, the industry is standing on the ground floor. The world is becoming more and more connected via APIs, and there is going to be no shortage of devices or pieces of software talking to each other. It is really just the beginning of anything related to APIs. It’s a big opportunity now, and it’s going to become gigantic.

5 Tips to Make an Outstanding Design Portfolio in the Startup World

Design Portfolios

Building an outstanding design portfolio has always been one of the greatest challenges of every college student who is interested in design-related jobs in tech companies and the startup community. It is even tougher for me because my major is totally different from design (I double major in business and japanese studies), and I only started taking graphic design and typography classes during my junior year at Yale as an exchange student. In the beginning, my online portfolio only had work from design classes, and it took me more than a semester to build up my portfolio with design work that I did for organizations and startups at Yale.

It was not until I was in Silicon Valley this summer that I finally had a sense of what an outstanding portfolio should be. After joining multiple events and portfolio workshops from places like AIGA, General Assembly, Facebook, Dropbox, and Airbnb, I discovered that what we encounter in art education does not always apply to the startup world. Product design is different from graphic design: an outstanding portfolio for a creative agency or a traditional design consultancy firm could be seen as superficial in the tech community. Here are 5 tips that could help your design portfolio stand out if you’re applying for a product design role at a tech startup:

1. Do Not Overuse Dribbble (or Behance)

Nowadays, it is really easy to find beautiful portfolios online on Dribbble or Behance. While the design communities on these creative platforms facilitate designers to share their work and design inspirations, it has already become a cliche to many startups who are looking for design candidates. There was one design talk that I went to in which the design product manager said that he would never hire designers who just showed him their Dribbble portfolios during the interview. Many product managers nowadays think that Dribbble is somehow too superficial if you’re doing UI/UX design — most of the displayed UI work showcases similar design trends and highlights colour palettes, fancy button styles, and other superficial details without really solving the actual problem (if there is any). The article “The Dribbbilisation of Design”  discusses this issue and shows 8 weather apps found on dribbble with only one that solves the real problem:

Designs that don't solve the problem

On Dribbble, you can find overwhelming displays of fancy lettering, illustrations, Apple-like aesthetics, and highly polished mockups that look perfect on every pixel. Many are just a regurgitation of design trends that most people know would look good — a new Apple logo design, a new Google homepage — without a more careful consideration on the usability, interactivity, and purpose. While Dribbble could be a good platform for sharing design just as how Flickr is for sharing photography, when you are actually applying for the job, you should break away from these common trends.

2. Solve Real Problems

Solving real problems is what makes product design different from digital art. A design that doesn’t fix a problem isn’t doing its job. Steve Jobs probably explained it pretty clearly:

 

  • Most people make the mistake of thinking design is what it looks like. People think it’s this veneer — that the designers are handed this box and told, ‘Make it look good!’ That’s not what we think design is. It’s not just what it looks like and feels like. Design is how it works.

 

Designers don’t just make things that look aesthetically pleasing. They have to think about how to interact with people, fix parts that are broken, create new concepts, and arrange components to form better systems. Therefore, stop imagining problems and redesigning existing brands — the new Twitter logo, the American Airlines rebrand — without understanding the organization’s internal philosophy and constraints. Instead, try helping your friends with actual projects that they are working on — it could be a college startup, a student organization, or a new app that your friend is creating — so that you could have better access to their needs, draft out pros and cons, discover tradeoffs and offer real solutions.

Another advantage of designing for real projects is that you can identify your success (or failure) to solve  the problem more easily. Sometimes, it is good to show how you failed in the past during your design interview if you are able to discuss with your interviewers your thought process and the things that you learned. Success can be defined in different ways, such as achieving an organization’s initial goals, improving certain key metrics, or gaining recognition from users, press, or the community. This applies to whiteboarding during interviews as well. When you are asked to whiteboard a design process during your interview, try to ask about the constraints and draft out problems that you need to solve and discuss how they are related to the key success metrics.

3. Show Your Design Process: It’s about the Ugly Sketches

Design process is the most important thing to make you stand out from other designers when the quality of work is very similar. People are very interested in your early thoughts and sketches, which usually involve ugly wireframe drawings on pen and paper. Compared with pixel perfect PNGs, the design process is more valuable because it documents your rationale and intentionality in curating different components of the whole system. Great portfolios often describe projects in specific case studies, showing all the previous versions of the product and explaining the intentionality of different components.

A proper design process should be top-down instead of bottom up. Instead of delving into the gritty details of grid, font, colour, and aesthetic style, designers should start from the business goals, the information architecture, the content planning, and the wireframing. We should also consider other aspects like interaction, product strategy, and ad positions (or revenue streams) before pushing the pixels. According to Julie Zhuo, the product design director of Facebook, her checklist of criteria for hiring designers goes through this process:

  • The idea: Does it solve a real problem?
  • Usability: Does the design show careful thoughts on how the product is used?
  • Craftsmanship: Details, quality, aesthetics, and craft

Most designers spend too much time on the third criteria without seriously considering the beginning part of the design process.

One of my favourite design processes documented by designers is “The Making of April Zero” (now turned into a startup called Gyroscope) by Anand Sharma, which not only included his sketches but also snapshots of his research and sources of inspiration:

 

The Design Process from The Making of April Zero

4. Link design with data

This is probably one of the hardest things to achieve for most designers. If you have data, you would probably stand out from many others during the design interview. No matter how a product looks, the ultimate purposes of design are user engagement and revenue. If you can get data from your previous company or project  — such as increases in calls to action, subscription rates, and revenue — and if you can delineate in your design process how different design decisions affect the outcome, you are ahead of the game. Apart from using data analytical tools in UI such as Google Analytics, Keen, and Mixpanel, you can also interview your users or other stakeholders about the outcomes of the project for qualitative information. If you can tackle this case study like how business students tackle their interviews for business consultancy firms — which often includes breaking down the conversion funnel and drawing diagrams that explain the increase in calls to action and increase revenue — this would help a lot.

One good example of how a portfolio incorporates design and data is this website that I found on the internet:

http://www.yeedor.com/

This is also good website to look at if you want more tips for conversion-oriented design:

www.goodui.org

5. Design Outside the Container

Product design extends beyond the interface of the product functions. It is about the whole experience. For example, designing empty states is something that many young designers miss out even though it is vital to first impressions and conversions. How notifications are designed, how marketing emails are templated, how easily a user can transition from your competitor to your product are also things that you can consider. It could also be an entry point to a new feature or a product walkthrough.

There are many articles about designing for empty states that you could look at:

Designingforrmptystates

http://tympanus.net/codrops/2013/01/09/designing-for-the-empty-states/

Many designers miss out this important step in product design. If your portfolio can take into consideration of the whole product experience, it shows your attention to detail and the maturity of your design thinking process.

Conclusion: It’s Time to Re-design Your Portfolio

These 5 tips are easier said than done. Even though I’m now working as a front-end web developer in San Francisco for my internship this summer, it will still take me a long time before I can actually fulfill all these expectations of an outstanding design portfolio. In the meantime, good luck with all the other student designers out there who are struggling with the same problems!