Out of the Big Black Box: The Happy Fun of Making Something New

will schenk

Will Schenk, Cofounder of the product engineering firm, HappyFunCorp, based in Brooklyn, New York, talks about his company’s role in facilitating new product development. Do you have a great idea for an app and there’s nothing like it on the market? Have you been “spinning your wheels” trying to get some heavy-duty functionality built into a client’s website? Do you need some back-end client-management tools to eliminate agency workload bottlenecks?

 

Or, is your client struggling with a product development/manufacturing snafu? Release date delays can cause “hurry up and wait” headaches for marketing. Your client may miss the optimal marketing season for his product (Santa Mouse toys will not have much market in January). After years of work, your client could lose the first mover advantage. As a marketer, you know your success is closely aligned with that of your clients. What do you do when your client’s success is beyond your control?

 

You think like a marketer . . . out of the box.

 

HappyFunCorp’s team of engineers helps early stage startups, people with a specific ideas, or larger companies trying to build the first version of a product by:

  • Clarifying the vision,
  • Identifying objectives,
  • Defining scope,
  • Optimizing user experience design,
  • Streamlining the development process to cut costs,
  • Leading the iterative process of product design and development by:
    • Utilizing demo-driven engineering to distill product concept essentials
    • Discovering, defining, and redefining the solution that best meets the client’s needs/budget
    • Pruning non-productive branches early on in the process to eliminate wasted time/effort/$$
    • Adjusting the development path as the product and the client’s needs are better fleshed out.
  • Branding and deployment

Will notes that the best solution is often not a given “thing” on a particular platform. Engineering development/client teams may conclude that the function of a “thing” better meets the desired objectives on a completely different platform than first envisioned.

 

Will can be reached by email at: will@happyfuncorp.com, through a contact form on the website at: https://happyfuncorp.com/, and on Twitter.

Transcription follows:

ROB: Welcome to the Marketing Agency Leadership Podcast. I’m your host, Rob Kischuk, and I’m joined today by Will Schenk, Cofounder of HappyFunCorp, based in Brooklyn, New York. Welcome, Will.

 

WILL: Good morning. How are you doing?

 

ROB: I’m doing great, how about you?

 

WILL: I’m good, I’m good. I had a long week, looking forward to unwinding a little bit this weekend.

 

ROB: Good time in New York?

 

WILL: Yeah, it’s nice. It’s much happier now that spring has actually come. The leaves are turning green, it’s a little bit less black. Everyone’s wearing different colors now. It’s got a little life into it after we slogged through the winter. So it’s pretty good.

 

ROB: Very cool. Why don’t you start off by telling us a little bit about HappyFunCorp and about what the company is great at?

 

WILL: Sure. HappyFunCorp is a product engineering firm. We work with a lot of either early stage startups or people with a specific idea or with larger companies that are generally trying to build the first version of their product—if that’s a website, if that’s an iPhone app, if that’s an Android app. Maybe they don’t even know necessarily what it is when people come in.

 

We help people take their idea and narrow it down into something that we can build and help build a process around how the idea can get developed. Everything including branding and user experience design right through to engineering and deployment.

 

We’re really good at fairly technical things and really good when it’s not super clear what it is when we start. We’ve done everything. We’ve started off with someone who wants to build a website, and then we’re building them an Apple TV app because it made sense at the time.

 

So we tend to focus in that part where everyone’s trying to explore an idea as much as it is to execute. All of the people here really love to dig into some meaty engineering challenges. So that’s kind of our sweet spot.

 

ROB: What are some interesting either types of application, or if you could even tell us particular apps that are out there that we can go play with that you can talk about, what can we play with that you’ve done?

 

WILL: God, this is terrible because we’ve done so many and I don’t have a list. [laughs] We’ve been around since 2009, and I think we’ve done about 170 different kinds of them. What are ones that we’ve done that have really worked out well?

 

Here’s an example of one. We did one called TeePublic. That is a website that you can upload your own designs for t-shirts, you can vote on them and decide which ones you like the best, and then of course you can order them and it’ll ship them to your house. That’s a good story to tell an example of how the product worked.

 

It started off, in the beginning they came and they wanted to build a Kickstarter for t-shirts. The way that the t-shirt business works, if you print under 150 them there’s one price point; if you want to produce 1,000 of them, there’s a different price point.

 

They were trying to build a Kickstarter type campaign where it was a site that was built primarily for artists, and they wanted to highlight artists’ work and get people to bid on these shirts to demonstrate there was enough demand for them, and then be able to sell them to the public.

 

Part of it was this whole credit card/reserving the money and advertising aspect to it, and the other part of the site was—What are the tools to build out that artist community to make sure that the artists are able to upload their images and edit them and fiddle with them on the site, and see what they look like with different color shirts and stuff like that.

 

That started off as a Kickstarter thing, and then, as the years went by, since they were able to do the volume and get the demand that they needed, they switched over and now it’s much more of a one-off, as-you-like-it design.

 

So our engagement with these guys started off with “we have this one idea that we think would make a lot of sense,” we figure out the technology issues and build that and get it in the market for them, and then as time goes on, as they really burn in their business, they realize, “Okay, we can polish off this rough edge here, maybe we want to refocus on this one feature and streamline a bunch of other ones.” It’s a very fluid process.

 

TeePublic is a very good example of one that’s actually gone out there and done pretty well.

 

ROB: Awesome. This process of helping people get the app that they want, I think a lot of times it can be hard to bridge the business and technical divide to get there. What is it, do you think, about you and your team that suits you to do this well? I say well; I haven’t personally had an app built with you yet, but a lot of people do.

 

WILL: Soon, yeah. Come and do it.

 

ROB: Repeat business is trust. What is it that you think makes you fit so well with that need that people have?

 

WILL: It is hard. It’s a super difficult problem when you want to start something in the beginning and you’re building some new technology. Technology has a lot of its own quirks and things. Developers will tell you crazy things, and you don’t know whether to believe them or not. You end up having to treat it as a big black box, and hopefully you find someone that you trust and is well-meaning and stuff like that.

 

Even then, if everyone’s on the same page, it’s still a hard thing to just get the technology out. Once you get the technology out, that’s the beginning of your process. It’s almost in some ways easier to build the site or build the app, and then the challenge really is around the marketing and distribution.

 

There are two things I think that we do very well, and one of them is the technology management of this—How do we take this big idea and help walk you through understanding and exploring what it’s capable of, and how do we make sure that we are able to commit to delivering something within the timeline and budget that everyone expects?

 

In the very beginning of the project, people don’t really know what they want. At the very beginning of the project is when we do the major product design phase. At that point, it could go in any different direction, and we need to figure out ways to take this very abstract, vague idea and show it to the client, show it to other users, even show it to ourselves and say, “This is really what we’re talking about.”

 

A lot of these things start off incredibly abstract. You’re talking about databases, you’re talking about wireless networks, you’re talking about video compression or whatever the thing is. It doesn’t really mean anything to anyone without having something tangible in front of them that they can see.

 

One of the things we do, we call it demo-driven engineering. Our whole process is focused around how we take that small thing that everyone agrees upon, everyone sort of nods along in the room when we talk about it, but maybe there’s a slightly different idea of what it is in your head than it is in my head. How do we collapse that so that everyone’s on the same page and we know what the design actually does and what it looks like?

 

We structure the process around those sort of realizations. What will happen is we’ll go through a design review and everyone will look at the mockups and nod along and say, “Yeah, this is great. This is exactly what I want.” Then 3 or 4 days later, we have it up on the site, people are looking at it—it looks exactly the same, but something is different between that time 4 days ago when everyone was nodding and this thing now where we actually see it for real.

 

That sort of realization is a continual part of the process. The engineering process of coming up with user stories and wireframes doesn’t really work for people who don’t live and breathe this stuff. Even if you do live and breathe it, maybe it doesn’t really feel right when you actually see it.

 

Those feedback loops are what we really try to have happen as soon as possible, which is really why we put emphasis on those demos, because you’ll look at it and people are like, “Yeah, that’s what I said I wanted, but it doesn’t really feel right.”

 

A good example would be we did a baby information tracking thing. A certain type of mother is very concerned about tracking how often the kid is breastfeeding and how often they’re changing the diaper and the various things that you want to do, as well as being able to take pictures of the kid. “Oh, my God, can you believe what he said this time?” and be able to take photos of this or capture thoughts and notes about it and then share that with—grandparents primarily, but aunts and uncles and stuff like that, other family members.

 

This is an application that helps you track all of your baby stuff and be able to share it with your family. As we built the first version, there was this concept of everything should be in an album and it should be discrete events. “This is a birthday party” and “this is a playdate” or something like that. As we went through and built it, everyone was like, “I don’t really care about the albums. I care a lot more about these individual photos.”

 

The functionality is very similar. You look at what we started out building and what we ended up building and you can definitely tell that they’re related, but the emphasis changes as every one of those things become real and people start to use it.

 

So the process is really focused around how you get to those weird realizations. We have names for them all. There are the “come to Jesus” moments. [laughs] These things where we’ve been going for so long with these assumptions, and then we get in there and we’re like, “Wow, I think we need to reevaluate that.”

 

We bake that into the process and say, “This is just what it’s like.” No one has the answers. We don’t really know what it is that people will respond to, and we don’t even really know our own minds. We certainly have opinions—we’ve been doing it for years—but our opinions are not infallible. The client is figuring these things out as they go.

 

It’s really difficult to get to something that’s simple, that makes sense to people. So that’s one of the main things that we do. We really focus around how we get to those moments of realization as soon as possible. If you have this in the very beginning of the project and you change the design, that costs nothing. If you have the thing deployed out there and there’s thousands of users on it, making some sort of fundamental change is certainly possible, but it costs a lot more.

 

So we help the client manage the capital that they have so they always are in a situation where they’re making small bets, they’re getting tight feedback around that, and then they’re able to deploy the money later on after the technology is crossed off the list. Now there’s something that’s working and they really need to focus on developing their customer base and running the business.

 

ROB: I would imagine in addition to new projects, you’re probably also brought in on, shall we say, “rescue missions.” Is that fair to say?

 

WILL: Yeah. We call them 9-1-1s. [laughs] We have a bunch of 9-1-1s.

 

ROB: Someone’s got an app they tried to build, it’s not quite working, they’re not making the progress that they want. What are the mistakes that you see people make that they come by honestly—I don’t want you to have to throw anybody under the bus—what are the common mistakes that someone might recognize in themselves, that they’re on a path to needing to be rescued?

 

WILL: By far the most common mistake is that people try to build too much. They imagine that their idea needs to have every feature in it for it to work. What will happen is that they’ll spend an incredible amount of time building out features that they anticipate that they might need, maybe. It’s almost a way to avoid getting feedback.

 

So first of all, people try to build too much, but then they also resist trying to launch. When you launch something there’s a big psychological fear that comes into play. You’re afraid it’s not good enough. You’ve tried all this stuff and now someone’s going to give you feedback, and people are terrified of feedback, as a rule—even though that’s the most important thing to get.

 

So they’ll push off releasing it, and they’ll say, “The ‘forgot password’ flow is wrong” or “We need to make sure the moderator tool does this”—they’ll come up with these things that you can argue are useful, but they’re really totally beyond the point of any valid thing. We need to get people on there, we need to see what they say.

 

That’s probably the biggest mistake that people make. They build too much and they are afraid of launching it.

 

Another very common thing that we see is that people have trouble with their engineering team. What they really want is a relationship with a product person, but they end up looking for—say I want to build an iPhone app. People say, “I need to find an iPhone developer,” which has a certain logic to it.

 

But a developer isn’t necessarily the person to help you figure out what you want to build or how you want to manage your overall project. A developer is much more like you tell them, “I want to build this video chat system because I want to connect therapists with people in rural areas” or whatever the idea is, and they’re like, “Great, yeah, video streaming codecs, no problem. We’ll get the database set up and we’ll figure out the bandwidth.”

 

What you really want is someone that’s more of an equivalent to an architect that would say, “Let’s figure out what the overall plan is. Let’s figure out how you want to present this to the user, and then let’s see which of these features are important to build or not.”

 

We find a common problem is that people have been working with engineers that are basically just doing what the client asks them to do. The client doesn’t really know how to build a product. Maybe it’s their first or second time. They’ve been working with someone that’s like, “Absolutely, I can do that, I can do that, I can do that,” and they just build stuff.

 

It’s great if you’re an engineer, but it’s like, you go to an engineer and ask them what they want to do and they say, “Let’s build something.” That might not be the right thing to do if your goal is to develop a product and build a business around it and get out there and work on something that will make a difference.

 

Those are probably the two biggest things. Either people build too much, or the relationship with the people that they’ve been using before isn’t really on the correct level. The people they’re working with would be fantastic as subcontractors, but they’re not the right person to say, “Let me simplify and help organize what your technology roadmap looks like, and then we can chip things off based on how we work with clients.”

 

ROB: That resonates really strongly with me. I worked on a kids’ game. It had been in gestation for over a year with an overseas development team, and they just had this habit of saying “yes.” That’s a good thing; you want to hear that when you have a vision for a product or an app, but you also need someone who will say “no” or “here’s a way that you could get 90% of what you want for 20% of the effort.” It’s a partner.

 

It sounds like you’re able to offer that partner level of sometimes saying “yes” and sometimes saying “no,” versus a developer who may just say “yes” and be happy to bill hundreds of hours.

 

Will, what led you to start this company in the first place?

 

WILL: My partner and I had a company before this. We raised a bunch of money—this was right around 2007-2008, so right when the financial markets got super exciting. [laughs] We were able to sell that company, and we wanted to keep working together. We had a good team of people, a good engineering and design team. Everyone had a great time working together.

 

So we basically started the company because we just wanted to keep the band together. We knew we were really good at the very beginning parts of these engineering projects. We found that space where it’s just as much design as technology, where you’re very focused on making something work with a fixed amount of money. We just found that space to be really interesting, and we love those sorts of challenges.

 

As we were talking to people, instead of joining someone else’s startup or having an idea that we were burning to do ourselves, we just started to help out people that were in a similar space. It was around 2009 that we really picked up. It was around the time when the iPhone App Store had just come out, so this was the next thing, so we rode that together.

 

Honestly, I never really expected it to be this long. [laughs] I kind of thought it would be 2 or 3 years and then we would move on to the next thing, but it’s been almost 10 years now. It really was just a desire to keep working and solving those kinds of problems.

 

Most of the project size when we work with someone is three, four, five people. Everyone’s super tightknit. There’s a lot of things that are simplified with the overall communication patterns because having a stand-up every day is like 10 minutes. It’s not an hour or whatever.

 

So everyone knows where it is, and everyone on the team is able to make significant contributions to the product. The technology guy who’s normally in there doing some basic plumbing stuff is like, “You guys are trying to do this; I think we could do something similar to it in a quarter of the time,” and everyone’s like, “Great, let’s go. Let’s try it.” Everyone is equally involved and motivated to do it.

 

We’re primarily an engineering company. We have a lot of design and a lot of product work. But in terms of just the number of people that work here—we’re at about 80 people now, and probably mid-50s of those are engineers of some sort.

 

Creating a place where everyone feels very actively involved with the projects they’re working on, they’re excited to go deeper into their craft and get better at the things that they really want to do—just from a running a company point of view, that’s a super important thing, to really make sure that we’re providing a good environment for people to work and do their best work because they’re excited to do it, because they have new challenges every few months, whenever a project turns over and they get to go on to the next thing.

 

That’s really the spot that we loved to be in, so we kept working on it. That’s how the whole thing happened.

 

ROB: That’s quite an achievement to go from, “This is fun for a while, let’s stick together for a bit” and now “Oh, surprise! We’re responsible for 80 people.” What have been some of the challenges, either expected or unexpected, as you rose to that many people in the company?

 

WILL: I think internally, my partner Ben and I talk about it as this is HappyFunCorp 4. In the beginning, when there’s five or six people, you don’t really need any structure at all, and you don’t need any bureaucracy.

 

Then as you get larger and larger, [you have to be] able to figure out the right type of administration to put in place, the right amount of internal bureaucracy to put in place where you’re able to stay true to who you want the company to be and who you are as a person, [but also] how to create an environment where people who have maybe different sets of values than the founder might have—like I’m personally not super into stability and security. These are not things that really loom large in my life, but a lot of people that work here want to know what’s going to happen in 6 months. They want to make sure that the paycheck will keep coming. You have to find a way to bridge that.

 

The one thing that has been a continual struggle is that my partner and I, when we started, we would do all the work. We would go in there and talk to a client, and I would do a lot of the engineering and he would do a lot of the product work. We’d be able to talk to them about business strategy, we’d be able to talk to them about invoicing. But as you create a bigger structure, you need to break down what each of those different things are that we do.

 

For the first couple years, at least, I don’t think we had any idea how we did what we did. We just went and did it. We’d both be able to wear however many hats were needed. We would be able to run the gamut of a huge number of different skills.

 

Now we have people and it’s broken down, and what one person used to do before is now split between six different people. Each of those individual skills—compared to our project managers, I’m a terrible project manager, but I was doing it before. Compared to the account managers, I’m actually not a great account manager.

 

We were able to break out these individual roles, which took an incredible amount of time, and we screwed it up plenty of different times. It took years to get it right for our specific business. The people that were good at one specific thing, while they would be a lot better at that given thing than we were, you really had to structure it a lot differently going from jack-of-all trades to individual experts.

 

That was something that I sort of understood going into it, but not really. That was one level that became very difficult.

 

I think the next level that was a big challenge for us was going from managing managers to managing people who manage managers. I’m so removed right now from the day-to-day of any given project that when I show up to a project, either it’s for a handshake and “Let me buy you a coffee,” or some sort of catastrophe has occurred. [laughs] These are the two times that I show up.

 

So I don’t necessarily know the ways that the project managers actually manage the projects anymore. That has been refined where I’m removed from that. That’s been another difficult step to take. It’s a further change from the way that I personally would do things as this first level of administration and process and procedures have been put in place.

 

And it’s a lot better than when we were doing it, definitely, both in terms of expectations and quality. We were all over the place when we were doing it, and now it’s a very tight process. But that process has been where I’m further and further removed from that. When it comes to delivering quality work for the clients, I think that’s actually way better.

 

When it comes to setting internal direction and communicating internally, that’s stuff that’s been hard to learn when you realize you’re actually quite distant from the projects themselves. The people don’t really want my opinion anymore. [laughs] They want me to come and fix some sort of fire, and of course ultimately we’re the ones responsible, so we have to go and do that.

 

But for the most part everyone knows what they’re doing, and we have to really step back and say, how do we do this two steps removed instead of one step removed?

 

Those have been the bigger challenges that I didn’t really expect. I didn’t really understand that going in. I think we knew how to do the projects, but understanding that you had to really break down the process and reconstruct it and then rebuild it—and that’s happened two or three times. Like I said, we’re HappyFunCorp 4 at this point.

 

So that’s been more of the process. Like I said, we just wanted to keep the band together, and we didn’t necessarily expect to do this, but this is how it ended up happening. The business part of it, the administration has been an interesting thing to figure out.

 

ROB: Got it. Have you got any events for the company or big launches coming up that we should be paying attention to?

 

WILL: We’ve got a couple things in the works. Next time you’re in New York, next time you’re in Brooklyn, you should come by. We’ll have a whole bunch of stuff to show. Unfortunately we’re not quite ready to put anything on the internet yet, but we do have a few things that are cooking. Especially for people who are in Brooklyn, or in New York anyway, we’re going to open up the company a little bit more to the community than we have before. We’re pretty excited about that.

 

ROB: That’s pretty awesome. Will, when someone wants to get in touch with you and HappyFunCorp, how can they find you?

 

WILL: The best way to do it is just email me, will@happyfuncorp.com. On our website there’s a contact form if you need it. We’ve got a little bit of a Twitter presence, and you’ll find us on there. But really, email is the tried and true way.

 

I’d be happy to talk through whatever, if people have something that they want to think about. A lot of times even just having a conversation with folks saying, “This is what I have with my team, this is what’s going on, is this normal?”, it’s good to bounce that off of someone. We live in the technology world, and I think everyone spends a ton of time on the internet, so we have a sense of what’s there, but it’s kind of hard to tell sometimes how hard things are or how easy things are or if what someone’s telling you makes sense or not.

 

It could be useful to have a second opinion, just to chat about it a little bit. Plenty of times I talk to people and they’re like “Yeah, that’s just normal and everything’s going great. It is actually just that hard,” which I think is also common. But yeah, happyfuncorp.com, that’s how to find us.

 

ROB: Okay, reach out to Will and HappyFunCorp. They can build you some pretty awesome things.

 

A special thanks today to Brandon Pindulic of OpGen Media for this introduction. Will, it’s been a pleasure. Thank you for sharing, and congrats on all the success so far.

 

WILL: Thank you. Thank you so much. I really enjoyed the conversation.

 

ROB: Have a great one. Thanks.

 

WILL: Thank you.

ROB: Thank you for listening. The Marketing Agency Leadership Podcast is presented by Converge. Converge helps digital marketing agencies and brands automate their reporting so they can be more profitable, accurate, and responsive. To learn more about how Converge can automate your marketing reporting, email info@convergehq.com, or visit us on the web at convergehq.com.

Leave a Reply

Your email address will not be published. Required fields are marked *