Tech In Boston

Tech In Boston

Sharing learnings on building a company, product, sales, marketing and more. Focused on Boston.

Coming Soon: Interview with Saty Mahajan, CEO, Mustbin

Coming on Friday 9/19: Tech In Boston Podcast Episode #15.image

Join the Tech In Boston email list so you don’t miss this episode when it’s released.

image

Saty Mahajan is the CEO of Mustbin, an app that provides consumers with a secure way to store anything using the camera on an iPhone.  Founded by Brian Shin, the CEO of Visible Measures, Mustbin was named Innovative Mobile App of the Year by MITX, and has been funded to the tune of $6 million to date,  including participation from Dharmesh Shah (co-founder of Hubspot) and Jonathan Kraft (president of the New England Patriots).

Saty was brought on as Mustbin’s first hire and built the product’s initial prototype.  He spent the last year running day-to-day operations as CTO and recently took over as CEO.  

In this episode, Saty talks about:

  • His recent transition to CEO and how he defines the role.
  • Creating iClub, a device that was was dubbed the “Future of Golf” by the PGA in 2005 and installed in top country clubs including Pebble Beach and Augusta National.
  • The biggest mistake that companies make in the early days of building.
  • Why something like free beer is a company perk - not something that defines the company culture.How to make tough decisions about what to build.
  • His thoughts on the future of mobile and the impact of Apple Pay.
Comments

What It’s Like Being an Engineer at a Startup

This is a guest post from Alex Meyer, Senior Developer at Privy.  Check out Alex’s blog for more of his thoughts on startups and technology.

Tech startups and engineers go hand-in-hand. At the core of any tech startup is a group of engineers. Engineers are the ones that put the ‘tech’ in tech startup. You don’t have to look very far for the mystique of the coder type. Even Hollywood is starting to get in on the action. But what is it actually like to be an engineer at a startup?  

Three Qualities of An Effective Startup Engineer

1. They need to be involved in more than just writing code.

One major difference between being an engineer at a startup vs being an engineer at a large established company is the opportunity to do more than just write code. Startup engineers have many different tasks and half of them do not involve code. For example, depending on the size of the company, there might not be a dedicated designer. That means, as a programmer, you will have to do everything from creating mock-ups, to designing prototypes all the way down to the colors of the buttons.

Before we had a full-time designer at Privy, I designed and implemented each part of the product that I worked on. That was true for every engineer. We had to figure out not only how something was going to work, but how it was going to look.

This is accurate outside of product as well. When a company is small, developers are involved in all parts of the business. Your skills will be required for marketing, sales, and customer support. There are no walls between departments at a startup, both literally and figuratively. Startup engineers have to dig in and help out in every way they can.

2. They need to adapt quickly.

Everything moves fast at a startup. That means an engineer has to be capable of adapting to changes quickly. Sometimes there will be new customers in the pipeline that require a particular feature and it gets bumped to the top of the list. Engineers need to be able to realize the impact it has on the business and drop everything to implement the feature quickly.

New people join and leave your team. When you are at a startup that is growing fast some employees will be joining the team and others will be leaving. You need to be able to get your job done with 2 people or with 10 people. Wherever gaps occur, you need to be prepared to fill them quickly. Sometimes that means doing backend work even though you are a frontend developer. Other times it will mean you have to learn new processes in order to be on the same page with a larger team.

Sometimes customers come across bugs that prevent them from getting their job done. These are the type of fixes that require programmers to drop everything they are doing and get a fix out asap. Fire drills happen and you need to be ready for them at the drop of a hat.

3. They need to get shit done.

It might be a little cliche but it holds a lot of truth. When all said and done, the most important quality of a startup engineer is to get your work done. Startups do not have long timelines. Most startups live and die every few months. Whether it is implementing new features in order to close a round of funding or fixing a bug that could cause customers to lose money, engineers at startups need to get shit done.

At tech startups this is especially true because the company depends on your work. You do not have time to sit around all day debating ideas when your business is hanging on by a thread. New features need to go out, bugs need to be fixed, and marketing needs help building that landing page. There is always something that needs to be done.

To be clear this doesn’t mean do crap work just to get something out the door. Instead, I mean that you have to do great work at 5x the speed. Sometimes compromises will have to be made but the effort you put in will be noticed and appreciated by the rest of the team.

Being an engineer at a startup is exciting. Few other positions offer the combination of the ability to influence multiple departments, learn at an accelerated pace, and have direct customer impact.

Check out Alex’s blog for more of his thoughts on startups and technology.

Comments

The OpenTable Of After Dark, MTV’s MADE & Managing HubSpot’s Brand

Tech In Boston Podcast Episode 14: Interview with Keith Frankel, Chief Digital Officer at Tablelist

image

Join the Tech In Boston email list and get new episodes delivered right to your inbox.

Keith Frankel is the Chief Digital Officer at Tablelist, a startup in Boston that has become the “OpenTable of after dark,” making it easy for people to book table or bottle service at any nightclub in New York, Boston, or Las Vegas (Tablelist raised a $2M round of funding on AngelList in July; read more about that and where the idea for the company came from here.)

Keith joined Tablelist from HubSpot where he was Head of Creative and Design and in charge of the company’s brand.  Keith helped HubSpot prep for the company’s recent IPO announcement, and he also heads up the Boston chapter of CreativeMornings, a monthly breakfast lecture series for the local creative communities of some of the world’s largest cities.

In this episode, Keith talks about:

  • His role as Chief Digital Officer at Tablelist and his time spent at HubSpot managing the company’s brand externally.
  • Why he left HubSpot prior to the company announcing it’s IPO.
  • The experience he got early in his career working as a product on the Emmy award-winning MTV show “MADE.”
  • Why writing has been one of the most underrated (and important) skills in his career.
  • The top three reasons he’s been able to become a successful manager at a young age.When “good enough” is good enough.

Comments

Delightful Utility

This is a guest post from Matt Brand, Co-Founder & Head of Technology at Dunwello.

Join the Tech In Boston email list and get new content delivered right to your inbox.

How do you decide what to build when you are just getting started? Having been a human my whole life (and now as a parent of relatively new humans), I am reasonably sure the human open source community has more information than the startup equivalent.

With humans, the feature set is fairly similar across the board: eat, move, sleep, causing stress for parents, repeat.

With a startup, the feature set is much less clear. The features you choose to build in your thing are likely different than those that I’ll choose to build in mine. We start with the problem that we think needs a solution or at the very least some improvement. That’s it. Now what?

I have a leaky faucet in my house? Great. I’ll go to the hardware store and get the tools I need and come home and fix the problem (or I’ll pay someone to do it for me). There are, of course, multiple ways to solve the problem. It turns out that the tools I choose are probably less important than fixing the faucet but alas, I must make some choices and I’ll typically choose a tool that I know how to use…unless of course I see a really cool looking new tool that I want to try. Either way, I must tell myself the following: “The leaky faucet is the priority.”

Then I need some validation. Did I solve the problem? With the leaky faucet, I think I can determine if the leak is gone pretty easily. With the startup? It isn’t so easy. We’re talking about having a problem, choosing tools we think will best enable us to solve the problem, and now choosing tools to help us determine how we’re doing; how to measure.

At Dunwello, we do a lot of measuring. We use some of the usual suspects of course: We got your Google Analytics and your Mixpanels of the world. We use NewRelic and we even have our own homegrown analytics we are developing. We also spend a lot of time talking to customers and getting direct human feedback. We even use that old-fashioned Twitter thing:

https://twitter.com/mattlauzon/status/504482709994217472

So back to the original question: How do we decide what to build? I think the answer is to trust your gut, your feedback, any information you have, and whatever guiding principles you’ve set in place as a company, and go with it. Step up to the plate and take some swings. You certainly aren’t hitting any home runs by sitting on the bench.

Now, whether you are a professional baseball player who hits homeruns or a home owner who fixes leaky faucets or a startup person who likes to build companies, it all takes practice and some trial and error. Even the best at their respective fields fail now and then. A hall of fame caliber baseball player might get a hit 30% of the time. So, you prepare as best as you can before you step up to the plate.

At Dunwello, we try to think of everything we do in terms of a DUI: Delight/Utility Index. Think of it this way:

image

Every decision we make for the company sits somewhere on that dart board. Of course, ideally, everything ends up on the top right where something is not only extremely useful but also a ton of fun. That’s not realistic.

The key is to not be judgmental about where things are but rather to just be aware. For instance, its important to have functionality that allows someone to reset their password. That feature isn’t likely to be delightful and it probably doesn’t need to be, other than it makes users happy if its easy. It is more likely the type of feature that will frustrate users if it isn’t useful. Password stuff is often high utility and lower delight. That’s ok.

Conversely, the Easter egg that was recently added to Dunwello is probably high delight and reasonably low utility.

Of course, when we started to discuss what our new homepage (now live athttp://www.dunwello.com) should do and how it should look, it was the kind of thing that we believed would be way up at the top right: very useful and very delightful. Every feature you build and every decision you make can have a Delight/Utility Index associated with it. I won’t speak for anyone else but when you start to put dots on that graph, each representing a decision you are going to make or already made, you can start to illustrate your company’s story.

If you have a better understanding of the professional story you’re telling, you can do a better job of telling it. If you can do that, then you will likely be able to better measure how others are reacting to it and what changes you need to make or where you try and go next.

Join the Tech In Boston email list and get new episodes delivered right to your inbox.

Listen to Tech In Boston on iTunes.

Comments

Teaching a Product to Talk

This is a guest post from Meghan Anderson, Product Marketing Director at Hubspot.  

Teaching a Product to Talk.  Thoughts on Product Marketing and Context.

One of my all-time favorite pieces of writing is an essay by Annie Dillard called Teaching a Stone to Talk. It’s about a man who works each morning to train a palm-sized beach stone to answer back.

It has nothing to do with product marketing.

It’s really about humans — and how we spend our days trying to coax the meaning out of things.

Which, of course, has everything to do with product marketing.

Because a stone is never just a stone. It is a puzzle piece. It’s an element to factor into your life and understand in full context. But stones (and complex strands of code) are really good at causing you to confuse the forrest for the trees. Particularly if you’ve spent some time with them. Particularly if you’ve held them at fifteen different angles and stared until you’ve memorized each solitary speck and glint.

A product will always present you with concrete qualities. It has four walls. It triggers alerts when a set of criteria are reached. It’s faster or more effective than its competitors. The challenge is in shifting your definitions from what the product does to what it means — what it makes possible for the world around it.

People think Apple is good at this, but in reality Apple spends a lot of time looking in the mirror. It’s just so damn exquisite that none of us seem to care.

Google is good at thisGE is really freaking good at this.

I can’t watch a GE commercial without wanting to call up my dad afterwards and talk to him about the wonders of modern life. How we can build anything. Solve anything. But it’s not just lighting and plot-lines that leads to this. It’s not that GE saw an opportunity to dramatize a stone and took it. Several years ago, GE’s entire marketing organization shifted its structure to ensure that context was built into their product blueprints from the very beginning.

Beth Comstock, GE’s chief marketing officer, explained in an April interview with Forbes, “GE is a Technology company, but technology alone doesn’t tell the full story… So, for us it’s been a big push to be technology-led as well as market-led. Marketing makes us more ambidextrous in terms of innovation by connecting the technology to needs, and to trends in the marketplace and make us more tethered to the market. We define marketing as a combination of value and innovation, and that means that we had to look at marketers as innovators.”

What does this mean in action? It means that before you build an ultrasound machine, you’d better understand how that machine fits into the larger panorama of hospital operations and global need. You’d better, as Comstock says:

“..Go to China, to talk to the hospital organizations to who say, we’re all about world health. We need an ultrasound to that we can, if not fit in our pocket, put in a briefcase. We can’t have one that’s the size of an air conditioner to go to some of the remote locations.”

Understanding that marketplace before a product gets there is as essential to telling the product story as it is to building the product. So marketing and product teams need to be side by side on it from the get-go. They have to see the gap together and envision respectively 1) how to fill it and 2) what filling it will mean for the people around it.

If you capture that inherent narrative from the beginning, if you understand the context into which it is born, the product will grow up learning to tell its own story. The lights and plotlines will be authentic, and the meaning won’t need coaxing at all.

This post originally appeared on Medium.

Comments