Building Great Products with Manifold

Product Development Interview

Disclosure: Manifold, the developer marketplace, has previously sponsored Hacker Noon. Use code HACKERNOON2018 to get $10 off any service.

If you missed it, definitely check out the interview I did with them last quarter, Building the First Independent Marketplace for Developer Services. Today, we’re going to catch up with Manifold’s VP Product Peter Cho to find out what makes great products. We also discuss what makes boring people boring, product integrations, and what it’s like to live for over 100 years.

David: On your LinkedIn profile, it says you worked at Heroku from 1900–2016. Do you think you held that job for too long?

Peter: Those of us who work in tech love finding new challenges and learning new things. A byproduct of this culture is that many of us swap through roles, companies, or careers every 1–2 years rather than really, deeply learning something (I’m absolutely guilty of this). Many of us are in this loop where we go to and from each of the major tech companies or cycle between the top players in our particular niche, at times even “boomeranging” back for round two. (I’ve left jobs where on my last day they winked and said “If you decide to boomerang back we’ll be here..”).

The great thing about this is that you get some awesome cross-pollination in the industry, spreading new ideas and processes in really short cycles. From a personal perspective, if done correctly you can also greatly accelerate your career growth. That said, it takes time to truly master something, and though I don’t believe we’ll revert back to being “lifers” at companies (e.g. IBM, GE, etc), I think we need to find a happy medium where people find career fulfillment for 5–10 years, even if it is at a fast-moving technology company. I think this will especially hold true as we start investing in deep tech, e.g. robotics, biotech, AI/ML.

In all seriousness though, I actually put 116 years on LinkedIn to throw off recruiters. Ever since I revealed myself to be a vampire they’ve stopped sliding into my DMs.

What makes a great product?

A great product is one that fulfills the promise it makes to users. Every product promises something, whether it’s an iMac, a stick of MAC lipstick, a Mack truck, or a Freddie Mac-backed mortgage. It promises to make your life easier, promises to make you feel a certain way, maybe it promises to provide nutrition. Bad products don’t fulfill their promise, they might be poorly designed laptops that run hot, have loud fans, and shut down a lot, making it hard to log onto Reddit. Bad products get your hopes up and shatter your dreams.

People like to say “oh, great products will change your life” and “they have to be world class” but I don’t think every product has to do that to be “world class”. You know, I don’t expect my living room rug to change my life. But when I bought it, I said as long as you provide me with some acoustic dampening, look nice and don’t shed, you are great in my book. I have bottles of hot sauce that promise to set my mouth on fire, and they do the job admirably. Those are also great products.

With Manifold, you can add all kinds of services to your stack (Bonsai Elasticsearch, Mailgun, LogDNA, etc.). How do you approach making the use of third party products within Manifold a seamless experience?

The one thing that blows my mind about developers today is how patient they are. Every time they need a new service, they’ll check Google, Quora, Stack Overflow, StackShare, inevitably spending more time researching than they probably should. I am absolutely guilty of this. When I was deploying my first application to Heroku, I spent more time comparing Mandrill to Mailgun than I did on picking my general practitioner, the person responsible for my actual health.

Once we do find a service that’s right for us, we create an account, set up a billing profile, find and read the relevant documentation, install the correct client libraries, and then go back to Stack Overflow to troubleshoot it. To be honest, that’s not a lot to ask for. You want a MySQL database? No worries y’all, I got this, be back in an hour. Oh wait, you want Email? ..and Monitoring? Redis? Elasticsearch? RabbitMQ? Memcache? Logging? Which credit card do each of these go on again? Frankie is leaving on Friday, which of these accounts were in his name again? Our credit card expired? Sorry, but I quit.

The flip side of this is that you end up locked into one of the big box clouds, settling for a bunch of white-label services. Listen, we want to eat Cocoa Puffs, not CVS Chocolate-flavored Corn-Spheres. We want the convenience of a big box, with the freedom to choose best-in-class developer services. With Manifold, you use one account, a single credit card, and provision any of the aforementioned services within seconds. You want a Redis database that you can share with your team? Two clicks. Do you want to use that with Laravel, Terraform, or Kubernetes? We’ve got you.

How and why did you end up becoming VP Product at Manifold?

They assure me that it’s not because I’m the worst coder on the team, but I think they’re just being nice.

Prior to Manifold, I was running Heroku’s Elements Marketplace. While I was there, the thing that struck me most was how early everything still felt. As big as the industry feels right now, there are so many aspects of development that are unnecessarily painful, and many people think AWS has won the day. What I saw at Heroku was that there is still a huge opportunity to empower and nurture the next generation of Twilios, MongoDBs, and New Relics, hopefully preventing a future Parse or RethinkDB from happening again. The cloud today is the tip of a very large iceberg, and there are hundreds of entrepreneurs out there that are willing and able to create the next generation of developer tools and services, they just don’t know it yet.

What are your KPIs for product performance? How did you choose them? And what KPIs did you once think, they may be important, but they weren’t?

Right now we’re really focused on onboarding, so funnel metrics are priority number one. What percentage of people are registering? Of those people, what portion verify, start to create a resource, finish creating a resource, and SSO into their dashboard? We’re dead-set on increasing these conversion metrics. Admittedly it’s not a glamorous answer, but we’re trying to be disciplined about the fundamentals before we get fancy.

Before this, we had a really long list of vanity metrics like # of users, pageviews, etc, which felt good but didn’t help us understand our business. We’re a small, over-leveraged team, so prioritization is key. We decided that we need to do one thing, do it really well, and create a focused petri dish of strong engagement. (Focused Petri Dish of Strong Engagement was actually the name of my high school band). You could have a really successful Product Hunt launch and generate a ton of users, but if they’re just signing up and leaving, they’re not providing much value. I’m probably not going to invite these people to my wedding.

Can you share some numbers about Manifold’s current usage?

David, I am a huge fan of full transparency and would love to show you all our usage numbers, but unfortunately we’ve reached the max # of users on our Mode Analytics subscription.

That said, my favorite number is 32, which is the percentage of users that come back for a second resource after provisioning their first. It’s a number we’re continuing to improve, and I love it because it shows the progress we are making on building a compelling, sticky product.

What does your day to day work app usage look like? How do you maximize your time in these apps?

90% of my time is in Google Hangouts, the other 10% is a mix of Trello, GitHub, and Slack (coincidentally, these %s also accurately reflect my laptops CPU and RAM usage).

Since we’re a distributed team with folks in San Francisco, Toronto, Hamilton, New York, Denver, Halifax, Fredericton, and Belgium, we rely a lot on tools that enable remote work. Most of our day to day happens in Slack, and we use Hangouts to coordinate, kickoff, and plan, the byproduct of which ends up in GitHub and Trello across our Engineering Waffle board and Product Roadmap boards.

Although I’m fairly happy with the current state of remote work apps, one of the things that we sorely lack is the ability to build camaraderie and create spontaneous watercooler moments. I’ve been pushing for us to incorporate apps like Overwatch and League of Legends to combat this, but apparently these aren’t considered “work apps”.

What changes to functionality of one of those products is an example of quality product development?

My favorite new feature of recent memory is the Shared Channels feature on Slack. It’s not something that would be immediately obvious, but it’s been a big pain point for me, across my last few roles. When I was at Heroku, we partnered with Facebook on an integration with Parse. I had to create a new standalone Slack instance and invite everyone involved to it. And then at Manifold, with our first dozen integrations we had been creating one-off guest channels and inviting users, but it just adds a lot of overhead. (Can you invite this person? Can you create a new account for this one instance?) Being able to create a channel and share it using the same account details is amazing, and they made it really seamless.

In building Manifold, what feature surprised you with high customer value? What feature surprised you with low customer value?

I mentioned earlier we’ve been really focused on onboarding. One of the things that surprised me the most is that the things you think are really obvious, are typically not that obvious to your users. The things that provide the most value are the little things that push your users into better understanding your product, which we often take for granted. We’d spend days writing and rewriting all this amazing copy, then realize that users were getting hung up on what a “resource” was. A “resource” is a thing we sort of invented, it’s an instance of a service that you’ve provisioned. However without context, it was confusing users in our tests, which is when we realized we need to either stop inventing words or we needed to spend more time providing education and context. Ideally a little mix of both.

In a similar vein, we’ll spend weeks or months building some “game-changing” feature, but take for granted that users might not understand or agree how revolutionary the feature actually is. Investing in the small things, in making sure your own biases and perspective don’t blindside you with users, is a “duh it makes sense in retrospect” lesson that happens more regularly than I’d like, but keeps us humble.

According to your Twitter bio, you describe yourself as “a boring person.” Could you share something you did today that is so boring that it is interesting?

My team’s reply to my first draft answer to this question was “you sound like a dad”. Which probably says enough in itself to explain my Twitter bio.

I do want to mention that beyond KPIs, day to day tools, or the gift of immortality, the single most important factor that determines whether you will build a great product, is whether you have a great team. I would be nothing without our incredibly talented product management duo Ming and Sitara, or the design powerhouse known as Meg and Nick. I would be a sad shell of a human being without them. Also, this interview couldn’t have happened without our marketing programs manager, Margaret MacAfee. If we’re being honest I’m just Manifold’s product puppet figurehead. Thus, boring person.

What’s the coolest new project built with Manifold?

Manifold! One of the most interesting projects we’ve got underway right now is figuring out how to build Manifold with Manifold. We’re going to be writing a blog post about how we made it happen, and how we use Kubernetes internally, so make sure to keep an eye out on our blog!