Category Archives: Startups

Straddling product and technology in large companies

Many roles at startups are for generalists. Most (good) startups want people who are interested in, and have ideas about, the product as well as the technology. This is partly because the product side of startups is generally immature — a consequence of not having reached product-market fit — and also because smaller teams make it easier for people to voice opinions outside the area for which they were hired.

As companies grow, this fluid movement between product design and implementation slows and becomes more formalized. Larger companies break down product development into¬†product managers, who have responsibility for product spec, and engineers, who control how the product is built. Good product managers don’t try to influence technical decisions, and many engineers are uncomfortable providing opinions on user-facing product features.

For people who move from startups to big companies, it’s hard to find a role that provides the same mix of product design and engineering work that you might do as a founder or early employee at a startup. The roles have simply become too specialized to allow for hiring a single person with impact on both areas.

While some of this specialization is inevitable to allow the company to grow, I think the best teams have a strong product orientation among all team members, whether their job involves programming, QA, or product management. The more the team leadership can do to extract product opinions from everyone on the team, the more invested people will be in the final outcome.

I’ve found the following techniques work well to get even introverted team members to voice opinions about the product:

1. Regular free-form brainstorming sessions about the product. It helps if these are focused on a few product areas, identified in advance, that you are soliciting opinions on.

2. Team-based playthroughs or walkthroughs of the product. Many team members have a hard time seeing the product in its entirety, and are focused on their piece of the whole. It’s useful to get the team together on a regular basis to try out the product. For things like multiplayer games, you can have the team simply play the game together for an hour. For less social applications, one person can demo the product to the rest of the team.

3. Feedback sessions about product roadmap, hopefully before it is committed to outside the team. Providing a coherent vision brings the team together and gives people a shared goal that they can stand behind. It’s even better if the roadmap incorporates suggestions from across the team, for greater shared ownership of the product.


Startup locations in the Bay Area

I’ve had occasion to speak with a number of startups in the Bay Area over the last few months. One trend I’ve seen is how many of them are located in San Francisco, in SOMA as well as other locations in the vicinity of Market Street. Two BART stops seem to cover a large number of these SF-based startups: Embarcadero and Montgomery.

It didn’t always used to be this way. When I first moved to the Bay Area, most tech companies — both established ones and startups — were in the peninsula. My first job was at a startup in Redwood City. SF was a city you used to drive through on the way to Marin County, and none of my friends from college worked in the city.

Things began to change around the end of the 2000s. I’m not sure what exactly it was — perhaps SF got really cheap or the peninsula got too expensive — but a lot more startups seemed to be popping up in SF. I met with an acquaintance at a game company near AT&T Park in 2010 and noticed how many tech companies I passed on the way to his office from the Caltrain station. The trend seems to have accelerated since.

It seems that there are relatively few new startups being started in the peninsula, and of the ones that are, many move to SF soon after their first serious round of funding.

I’m interested to see how this trend plays out. Being in a city definitely has its advantages in terms of attracting a certain type of employee (generally younger and single), but it may have adverse effects on hiring more experienced employees with families. It may also limit the radius within which companies can hire — unlike mid-peninsula locations like Palo Alto, SF is hard to reach from many places in the Bay Area (and much harder to find parking in!).

Be that as it may, I now have several friends who commute up from the peninsula into the city every day.

The Last Mile Problem

One of the things you hear most often about Indian infrastructure, especially telecom, is the “last mile problem”. While the telecom backbones within the country are fairly robust, actually getting physical connection wires into a customer’s premises is problematic and failure-prone.

I’ve had a good opportunity to observe the last mile problem play out fully over the last few months with the Internet and phone connection at my office.

The connection was first set up in June. Since the building is old, it didn’t have a connection to the provider (Airtel)’s distribution network, so the first installation technician they sent did whatever it took to get the connection going. This meant stringing a wire from the nearest telephone pole, in the air across the street, and then taping it all around the building to the nearest window from my office, and then hooking up the cable modem inside the office to that.

I felt this state of affairs was unstable and could be brought down by rain, or something even more dangerous like a gentle breeze. After repeated calls to the customer service number, they sent out another technician, who now encased the wiring around the building in a PVC pipe to protect it better. We were still getting our Internet connection through a wire thrust through our window.

Yet more phone calls yielded one more technician, who went a bit further. He was now able to connect their wires to the building’s internal phone wiring (it did have wiring, thankfully), so that we could now plug in our cable modem into the phone outlet in the wall.

All this time the wire from the telephone pole suspended 20 feet in the air was still our Internet lifeline. The ISP was reluctant to change this since it meant digging an underground cable into the building for them. After much follow-up, they finally agreed to do this. A (small) army of labourers arrived one day and installed a “distribution box”, or DB, on the building premises. The location of this box caused some controversy among the building residents due to NIMBY-related concerns, but some negotiation took care of this. The DB was then connected through an underground pipe to the nearest point – luckily, just outside the building – that had a connection to the ISP’s backbone in Chennai, and the PVC piped-wiring attached to the building (which was itself finally connected into the building’s internal wiring) was plugged in on the other side.

We now have:
1. A cable modem in our office, connected into a wall socket, that provides us with beautiful data bits;
2. A PVC-encased copper wire circling the building;
3. Not an exposed or hanging wire in sight.

Could life get any better?