Family Fire Safety Tips

From Bob the fireman.

Bob is real, he is awesome and he loves to remind us: “come on, you are my neighbor.”

Bob has been a Boston city firefighter for 34 years (as of last week!). He’s a level-headed dude and he’s seen a lot of sh*t over the years.

Following the tragic death of a woman our age a single block away from us, I stopped him and asked him to talk shop: How do we keep our family safe? What’s our *plan* if we find ourselves in a fire situation?

And from the conversation, I present to you, dear reader … these tips.

  1. No space heaters. Don’t use them. The inexpensive ones claim far too many lives of low-income families that are just trying to keep their babies warm. I prodded Bob to see if he thought better units were in fact better and though he clearly didn’t want to hurt my feelings I could see his #1 recommendation was simply to never ever ever use a space heater. Ever. 34 years … I’m just going to believe him and throw my space heater away.

  2. Size it up. The first thing you do in a fire (and this is the first thing a firefighter often will do before heading into a building) is to determine the source of the fire and from *every* place in the building you may be know how you will get out immediately. “And don’t take your time figuring out where the fire is either” (goosebumps). If you can determine where the fire is, go the other direction and get out of the building. Which leads us to …

  3. Get the f*ck out of the building. Main reasons people die in fires: smoke inhalation and carbon monoxide poisoning. You know what doesn’t sound good but is a lot better than that? Jumping out a second story window and breaking your leg to save yourself. That’s what casts and doctors are for. Get . The. F*ck. Out. If you see a way out that looks safe for the moment, just go. now. go. get out. be out. live.

  4. Save your baby. We’re parents, we’re going to get our kids before we get out, so do it, do it fast and (remember #3?) know how to get out from your kid’s room if you get cornered by a fire.

  5. Work with your neighbors. If you share a building with other units, get the other folks on board. No space heaters. Replace batteries and smoke detectors and carbon monoxide units regularly. Take this stuff seriously.

  6. Carbon monoxide units save lives. Get them and maintain them.

  7. No open candles. Come on people.

  8. Prepare for basic scenarios with your family. Panic is the enemy in emergencies. Run through several basic scenarios of fire in the building with your family (at a minimum your spouse/partner). Determine the fastest way to get out of the building from any location inside.

Disclaimer: These tips do not constitute legal, medical or civic advice and only serve as an anecdotal and informal starting point for your family to consider the gravity of fire emergencies and to urge you and your loved ones to research and discuss and prepare. Visit your local fire department to learn more about home fire safety.


Two Keys to Building a Great Product


In the product group at HubSpot there are two guiding principles to building amazing products, they come from David Cancel and he’s 100% right in my experience:

  1. Be customer-driven
  2. Show meaningful progress

Each of these means different things at different stages in the product lifecycle, but they are strong guiding principles from early stage research through MVP to mature product.

Here’s a starting point to think about how to lean into each of these principles, and a view of how that changes as a product comes to market and matures.

  1. Customer-driven: Narrow your focus to your target go-to-market end user. Find where they spend their time, where their pain is. Watch them in their natural environment. 
  2. Meaningful progress: Consider doing a minimum of X interviews, and/or defining the output as being the top Y painpoints to start addressing.
  1. Customer-driven: Be insanely impatient to get an early working product in front of one user. That’s the hardest part, getting one person to the point where they would pay, or be seriously disappointed if you took the product away from them. super hard stage, from zero to one user. Then move from one user to ten, another extremely hard stage. Put your cell phone in the product, follow up with people as they use the product, and watch every motion they take using it. Start doing user testing as well.
  2. Meaningful progress: Live and die by activated user count. From zero to one, and from one to ten. 
Growth phase
  1. Customer-driven: The product team should directly support their customers. When applicable work with sales to understand how to iterate on *validated* learnings - not “all i need to close every deal is XYZ” requests but actual records of painpoints, blockers, competitive landscape, potential for product differentiation, shortcomings against existing solutions, etc. It helps here to have consultative sales folks who don’t do “feature dumps” but rather do a great, scalable job of customer pain discovery. If product/dev can overhear these conversations some magic can happen :)
  2. Meaningful progress: Measure, chart and distribute to the team: active users, activation rate, recurring revenue, net churn, referral loop, tickets/customer (whatever makes the most sense as a yardstick for product/market fit). Company demo (monthly) of new features LIVE for real customers, not mockups or qa.
Mature product
  1. Customer-driven: Record and distribute top support inquiry drivers, measure decrease in these drivers month over month. Heavy use of user testing to optimize the core flows and usage patterns in the product.
  2. Meaningful progress: Measure, chart and distribute to the company: tickets/customer, call drivers (and delta month-over-month), uptime/availability, performance/speed. Continue company demos, include performance improvements in addition to features.

Hope someone out there finds this useful, it’s been a breakthrough for me and my colleagues to embrace these principles and to dive deeper and deeper on both.


Dig this stuff? Come work here.

3 Real Lessons from the Mailbox Acquisition

  1. Understand what job your customer hires your product to do.
  2. Your inbox is (still) the center of your universe.
  3. Companies want to buy solutions to hard problems outside their traditional focus, not build them.

Mailbox understood the job that we hire our mobile email clients to do. This job is NOT “to provide us access to all our email messages and an easy way to reply to them.”

So … why do we take out our phones and check our email?

The Mailbox product team knows we hire their app to be “all done” with email. This simple realization led quickly to a complete rethinking of an email application. Kudos.

Email isn’t going anywhere, it’s the center of our universe and the one thing we ALL check all day every day. It’s still a terrific place to invest, especially when huge realizations like the point above are still out there.

When a company applies laser focus to particular problem space - like Dropbox did with transparent file synchronization and sharing - it often helps them achieve rapid, decisive success. The downside to this focus is that it becomes challenging, perhaps even insurmountable, to tackle, rethink and dominate another problem space with similar potential.

How to Win

He was an odd fellow, not unlikable or strange, just quite certainly different. His gait was a bit oafish, almost certainly due to his tall, looming frame. The boy was a sort of caricature of a high school student, growing into himself and learning to play off the perceptions and perspective of those around him.

For Halloween one year he appeared in the costume contest wearing a too-tight white undershirt with the school principal’s name scratched on the front in big block letters. Purely absurd, the “costume” led the boy to bear absolutely no resemblance to the short, bearded and bespeckled school leader. It was hilariously perfect, a proto-hipster moment of irony a decade ahead of its time.

Over the years the young man formed a band that would play occasionally on weekends, in the corner behind some lunch tables. The boy himself was not much of a musician, nor were those he had recruited to join him. It didn’t concern him in the least that only a few in his group really knew how to play their instruments. They played and played and played, their fearless frontman wheezing out Soft Cell, wielding a toy keytar. They had a blast.

And it so happened that this particular gentleman simply didn’t stop … he would sit in his room for days writing and recording and writing and recording and playing and singing and writing some more. Supposedly he and his friends wrote and recorded a whole record in a day once. Maybe it was terrible, it didn’t much matter. He learned, they grew, and kept going.

Everything we make goes away, the code we write, the product we ship, the furniture we build, the clothes we buy, the meals we make.

Make something useful and enjoy the process, learn from your efforts and be prepared to let your work pass away into the ether. There are always more ideas, more projects, more excitement, more value to create, so give yourself the courage to go harder and faster. Be fearless.

The young man was named Win.

He won the costume contest. Years later he and some friends won Album of the Year.

Keep going. When you are scared or tired, when you doubt yourself, when you don’t think you have enough skill, enough experience, enough talent … just go harder.

Demoing Product

Most product demos are disastrous. I’ve gone through more trainwrecks than I would care to have, and thought I’d share some of my scars and random learnings on the topic.

  1. Beware the projector. These things are the devil. You have three challenges here: a) severely limited resolution b) severely limited contrast and c) unpredictable connection to the demo machine. Mitigate the first by bumping up the resolution as much as possible, and using browser zoom to position your (web) product correctly. Regarding contrast, be prepared for your product to have far less visual impact compared to your cinema display; if your product has a dark background with lots of sleek grays (think Spotify), be prepared to explain why the app looks like a pile of melted driveway sealant. As far as the peripheral connection s concerned, be sure you know how to resync displays, and also to have tried that particular projector with the demo machine prior to the demo.
  2. Tell your team. It’s amazing how often a fatal flaw in a demo happens because the development team is completely unaware that the demo is taking place. Advise your team to stop shipping for that period, starting an hour or so beforehand. Also be sure that the hardware on which the product is deployed is appropriate and prepared for primetime. I have some ugly stories from the trenches … in fact that reminds me, make sure that YOU know the product is being demoed.
  3. Narrate the user experience. Speak in the first person, commenting on your experience moving through user flows. This technique will keep you on-task, focusing on use cases and the end-user benefit of the cool new stuff you’re showing.
  4. Demo in production. If there are any stakeholders in the room and you demo software that is running locally, you are willfully deceiving these people as far as I am concerned. No QA/dev environment demos … prod or it didn’t happen.
  5. Use your computer. Or one just like it. If you rehearse on a Mac, demo on a Mac. If you have to swap presenter roles, it’s worth it. By the way if you are in fact on a Mac be sure to use the presentation mode in Chrome. Try to use the same version of the operating system and - bonus tip - clear your browser cache. Another one, make sure you remember any logins/passwords you may need.
  6. Set up early. If you are walking into a room full of people and plugging your computer into the projector, get ready for a big healthy serving of fail. Ideally you will being preparing 15 minutes ahead of the demo start time. Edward Tufte makes this recommendation as well, regardless of whether you are demoing a tech product - his point is that you should be ready to go, calm, and ready to get a sense of the audience as the room fills up. Also, people will be trying to talk to you as they enter the demo room, and if you are ready to go then you can afford to not blow them off! It goes without saying (or not, apparently) that preparing ahead of time will give you a fighting chance to resolve last minute issues.
  7. Test all features within 10 minutes of the demo. Obsessively, whenever possible.
  8. Demo mobile and tablet apps using a visualizer. It’s not cheap, but it’s by far the best way to demo small-format mobile interactions. Get a WolfVision or similar. Justify the cost by using the hardware to produce high-quality product demo videos, and to demo at tradeshow booths (they work extremely well for both purposes).
  9. Hardwire your internet connection. And beware of Bluetooth. Wireless technologies work much better in empty rooms than in rooms full of web geeks. That one hasn’t burned me personally, I learned this lesson at the expense of the GoogleTV team.
  10. Stay positive. We invest ourselves in what we make. We burn the candle at both ends, and fight to motivate our teams and those depending on us. We make our own mistakes, and pay off the mistakes of others. By the time a demo takes place, a lot of love and pain has been poured into the product. Check any personal bullshit at the door and just tell the story of why the software will make someone’s life better - that’s all anyone wants to hear.
What is product management?

What is product management?

This is Broadway

Most likely we’ll do several things over the course of our career, maybe 6 or 7. If we’re lucky we’ll do interesting work, or if we’re really lucky, work that we genuinely enjoy.

It is an uncommon and fortuitous opportunity to have work that is fascinating, challenging, enjoyable, and that can leverage an existing force of nature and become simply unstoppable.

This is the situation at HubSpot right now.

Watch the next 6 months. This will make history. This is fucking Broadway … time to play.



Ben M Greene: Why Continuous Deployment Matters


Here at Boundless Learning, we implemented continuous deployment about six weeks into the start of the company and over four weeks before launching our first alpha release. Why was this so important to us? Because we wouldn’t have it any other way.

Continuous deployment is more than a…

How to Turn Hate into Love

Love or hate are the signs you’re on to something. Indifference is to be avoided. - @dcancel

The above represents, for many, a confusing and even troubling statement. If you are aiming to build an amazing product, why on earth would you want people to hate it?

Building a world-changing product is quite difficult, and like any creative effort is largely the process of making thousands of decisions correctly - and fast. Your greatest weapon is your evolving instinct, or what can be thought of as the scent. Being on the scent is key to moving quickly and with confidence, and to shaping the future with tremendous velocity.

When people use your product and hate something, you’ve picked up on the scent. Why do we most commonly hate things? We hate what is different, we hate what is surprising, and we hate what we do not fully understand.

If no one ever hates anything about your product, there is a good chance you are trying to build a “faster horse.” Fierce objections to a feature or approach indicate a break from the traditional worldview, and therefore an opportunity to change the world.

When you find yourself hating a feature or approach, abscond with it. Build it. Mold it, understand it, shape it, turn it on its axis and view it in different light, throw it away and remake it.


I hate real time analytics. It’s been my view that streaming data is fluff, never actionable, and the architectural decisions required to support real time analytics are catastrophic. It has been said that the one secret to building an analytics application is to never ever promise real time reporting to anyone.

We have some real time data feeds, mostly for debugging and validating data collection, and recently I sought out to better understand real time analytics using these raw feeds. As a matter of fact, it was the result of David prodding me to skunkworks a ‘newsfeed’ feature. True story: when he asked that we build it so we could understand it better, he looked up from his notes, smiled and said “you’re going to hate this.”

I spent a weekend hacking our raw feed into a rough alpha feature that I could expose to some of our customers. The feature as it is will almost certainly never make it into production on a wider basis, but it’s something, it’s real, and we can play with it and understand it better.

Playing with this basic feature has opened my eyes to use cases I had never imagined. As we get feedback from customers the vision for what we can do with real time analytics becomes clearer, and I absolutely love where this goes. Stay tuned.

Another example is our individual view, a CRM-style presentation of a customer showing their interaction history, acquisition source, and so forth. We have the pleasure to work with one extremely talented marketer who from the very start absolutely hated this feature. And why not? She is measuring and optimizing an ecosystem of millions of users, so how could a person-level view possibly be useful to her in her daily work?

As it happens, everything she wants to be able to do that she cannot do with traditional products is made possible by this feature. She loves the way we are different and believes we are changing the world. Her hate of one feature was just more confirmation that we are on the scent.

And being on the scent is pretty thrilling.