Taking the leap

To many I’ve talked to recently, this isn’t necessarily news . . . but about 7 weeks ago I left my very, very good job as a product manager at InsightSquared. InsightSquared is doing really well. And I enjoyed my 19 months there. But it was time to leave. I’m incredibly grateful to the folks at InsightSquared. Folks like Sam and Fred and Bryan gave me a ton of autonomy and a big challenge. But . . .

It was time to leave because I had completed that big challenge they initially had given me.

It was time to leave because it was a little too early to leave. And I’d never left a job too early. Always too late.

It was time to leave because I couldn’t shake the idea that it was time for me to challenge myself as much as possible and try to start my own company.

It was time to leave because my risk profile allowed for me to take a big risk this year. (By the way, my wife is really incredible and I am one super lucky guy).

It was time to leave because I am excited about trying to help folks with Fulfilled.

So I have turned my side project at Fulfilled (p.k.a Diseer) into my full-time job.

I’m currently working on Fulfilled full time, getting some help from some friends part-time and starting to build a product. We’ll see how it goes. If you want to keep tabs on Fulfilled, subscribe to the blog. Or even better, sign up to use the product when it is made available. Go on, sign up.

My Current Side Project

Hello loyal blog readers,

Just a quick post to say that most of my deep thoughts outside of my day job at InsightSquared are being put down in writing at my new side project, Diseer. Head on over and check out my writing on you and your career path over at the Diseer blog.

So go on over there, check it out and let me know what you think.

4 Lessons Learned Working at HubSpot

After two great years, I left HubSpot last month.

I’m not sure what’s next, so don’t expect a forward looking just yet. Right now, I’m focused on taking stock of all the things that I learned from HubSpot, all the great folks with whom I collaborated and the new perspectives on the software business I gained. HubSpot is an incredible place — I learned a ton. Here, mostly for my own documentation, are a few of the key lessons that I either learned or were reinforced working at HubSpot.

1. Be unafraid to make aggressive changes

This is the thing I would emphasize more than any other. At HubSpot, things are generally going well. Its no secret the business is growing. I think one of the reasons it continues to grow is that leadership team is unafraid to tackle problems with big changes. They don’t save big changes for when the business is facing big, threatening problems. They are aggressive in solving the monthly/quarterly problems with bold change. It pays off.

2. Transparency empowers

I have never ever worked at a place as transparent and open as HubSpot. Virtually everything you’d want to know about the business is known and shared on the HubSpot wiki. To paraphrase Dharmesh, you need to have a really good reason to  keep something a secret at HubSpot.  With more people empowered with more information, better ideas are generated, millions of small decisions are better informed and the business just runs smoother. People trust each other with open transparency.

And this extended to our relationships with our customers. We were able to more effectively work through problems or changes with the product by being 100% honest with our customers at HubSpot. The more they were informed, the more our customers trusted our judgement and accepted changes to the HubSpot product.

I loathe the prospect of ever working somewhere that wasn’t as transparent and open as HubSpot.

3. The answer is always “ship it”

Hat tip to David Cancel here. As a product manager, you’re not always sure when to ship something or take the next big step. And the answer is almost always “ship it”. Should you wait for the next round of imminent improvements to the tool? Do you wait for another round of performance improvements? Do you wait for the next round of UI tweaks? Don’t wait. Ship it. Those improvements might end up being the least important thing you should be focusing on. Your priorities need to be customer focused. And if you are teetering on making something more widely available, just ship it. You’ll learn from your customers if your priorities are right.

4. Use good judgement

This one comes from observing Brian Halligan. Occasionally there would be some cultural question or some HR policy debate that would bubble up. And eventually, Brian would weigh in with his “ruling”. And it would almost always be “use good judgement”. Should you come into work when you’re sick? Use good judgement. Should you come in when its snowing? Use good judgement. How should you behave on social media? Use good judgement.

If you have adults at your company (and having aged a certain number of years doesn’t mean you are an adult — I forget where I stole this idea from), trusting them and empowering them to make their own decisions ensures happy employees, and usually the right outcomes.

(Ex-)Hubspotters, what did you learn?

DevOps so easy a 5 year old can do it

Last weekend, I was worried about the operational state of our analytics pipeline at work. For the uninitiated, its basically a series of ‘jobs’ that process records from each page view on our customers’ websites and tabulates all sorts of reports from that data. It runs 24 hours a day. It usually runs smoothly but occasionally it’ll have a problem in production that we need to solve. And since I’m the earliest riser on the team that is responsible for it, when I wake up, I check on its state. Lets level set though — I’m a product manager, not an engineer. I’m not doing anything heroic here. Pretty much the best thing I can do at 6AM when I wake up and see that the processing is heading in the wrong direction, is say “crap, someone smarter than me needs to wake up to fix this”.

So part of my responsibility is monitoring the well-being of our operations. But another part of my responsibility at 6AM is my kids. I can happily live on less than 7 hours of sleep which means I’m ready to rock and roll with the them on the weekends when the kids are up at 6 AM. So last weekend, I find myself downstairs with my 5 year old. I’m moderately concerned with the state of the pipeline in our production environment. I have my laptop out and am checking out our monitoring tools. But my 5 year old son is, you know, 5. And he’s hungry because its been something like 12 hours since the last time he ate. And expecting pancakes.

So I do what every geek dad would do. I give a 30 second explanation of what a flow diagram is and the meaning of the colors on the graph of the flow diagram in question. And then I put him to work. Because there are pancakes to be made. The following ensues:

I don’t generally post things publicly with my kids, but I thought this was cool (and I figure he’s facing away from the camera).

Every production process should be this easy to monitor and watch. Of course my 5 year old (or me) can’t do anything if those boxes turn the wrong color, but  . . . my 5 year old understands what’s happening and is pretty close to being able to identify if a Bad Thing is happening. The data visualization is simple and it works. Its intuitive. The design is pretty rudimentary in terms of styling but the visualization of the data delivers a clear, easily understood story. Not too much to juggle and a mere mortal gets it quickly. It solves a key problem – informing a broad set of mortals in our organization how key operations are executing. The more people in your organization who understand the state of your most complex operations, the better you can all do your jobs. I love love love it when I stroll into HubSpot’s support area and see folks looking at this and other operations graphs. Your entire operation works more efficiently. Support teams can respond in real time to customer inquiries without “asking the engineers” and engineers are focused on either moving your product forward or solving the devOps problem du jour without major distraction.

Anyway, thought this was too good to not share. Enjoy.

3 Most Useful Blog Posts Ever

What blog post has been most useful to you?

I find myself constantly referencing useful blog posts in my life as a product manager. Not only that, I tend to go back to a few key posts, by a few key influential bloggers. I thought I would recount the 3 most useful blog posts I’ve ever read, as determined scientifically with complete and absolute statistical certainty.

1) I should start with Joel Spolsky since Joel on Software was probably the first blog (in the dark ages of blogs) that I ever read. I started reading Joel on Software when I was working at Kenan Systems as a release project manager for the software product. Aidan, one of the engineers suggested I read a website that he enjoyed. In no time, I was devouring every article in the archive. This was probably 2001 or 2002.

Joel wrote a ton of great posts — if you’re in the software building business, you should certainly go read his greatest hits, at a minimum. But the one that stuck with me is the one about rewriting software products. It probably sticks with me because of the firmness of the advice — rewriting your code from scratch, Joel writes, is “single worst strategic mistake” a software company can make. Not only that, its advice I find myself calling upon, every day. At any company, there’s production hardened code. And it has flaws. And its in outdated, hard to use languages. But “when you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work.” Its a calculus I find myself walking through very often these days. Its timeless advice.

2) I read Fred Wilson every day for a very long time. Much of the time I was at IBM. It was like he was writing about an alternative reality to my every day life in enterprise software.

But the moment I joined HubSpot, his knowledge skyrocketed in important to me. The one post I find myself repeatedly referencing is Fred’s 10 Golden Principles of Successful Web Apps. Especially influential has been his point about “instant utility.” Maybe this resonated with me because “utility” is probably the only concept from philosophy class I remember. But more likely because its the absolute key to many of the most successful elements of the HubSpot portfolio. If your website or product doesn’t quickly deliver something useful to the customer, then you’re doing something wrong. The closer to the consumer market you get, the more important this advice is. I bust out this blog post at least once a month in product design discussions. I think the HubSpot wiki must have at least 2 or 3 comments of mine linking to it.

3) Last, but certainly not least, is Marc Andreesen. Andreesen is like the EF Hutton of the software world for me. When Marc Andreesen talks, I listen. When he was actively blogging on his personal site, the signal to noise ratio in his blog was off the chart. His writing and perspective was incredible. I vividly recall reading his take on the financial meltdown — and how he basically called it blow by blow.

But his post that has stuck with me and helped me in my career was his writeup on personal productivity. A few days ago I wrote about one element of this post — not keeping a schedule. More so than that advice, I’ve consistently tried to adopt almost every day since is the suggestion around keeping a 3×5 card with my daily to-do’s. Andreesen writes:

I sit down at my desk before I go to sleep, pull up my Todo List […] and pick out the 3 to 5 things I am going to get done tomorrow. I write those things on a fresh 3×5 card, lay the card out with my card keys, and go to bed. Then, the next day, I try like hell to get just those things done. If I do, it was a successful day.

As I read elsewhere, keeping the list for a single day keeps me focused and the satisfaction of physically crossing off the completed items is immensely satisfying. Andreesen’s other suggestion about “productive procrastination” is also golden and recommended. All that blog reading when I should have otherwise done work has paid off.

What blog post has been most useful to you?

Changing Jobs, Changing Control

I came to HubSpot about 14 months ago. It was a big change for me professionally and personally. At the time of the change, I wrote a bunch of posts on this blog recounting the job search process and my adjustment to life outside of IBM and to a growing startup. With a full year under my belt, I gave some thought to the biggest changes and adjustments. The conclusion I came to was that I now have so much more control over the course of each and every day – and its incredibly liberating and satisfying. Its not that big bad controlling IBM didn’t give me autonomy — it did. It gave me a remarkable amount of control over big decisions for the products I worked upon. This feeling of control and liberty came more through the mechanics of no longer needing to coordinate and collaborate with the web of IBM colleagues and peers. Here are two examples

1. Meetings.

My volume of meetings went from 6 – 9 hours of daily meetings (primarily conference calls) at IBM to . . . well, most typically 15 minutes a day. Maximum at HubSpot, I have 3 meetings in a day. Whereas at IBM there are all sorts of status meetings and coordination meetings and pre-meetings and review meetings, at HubSpot, I have none of them. This is a good thing not because meetings are de facto “bad”. Its more an indicator that the nature of my job changed entirely. I went from a place where I was keeping a manager’s schedule to a place where I was keeping a maker’s schedule. There is now at HubSpot a clear expectation and an actual opportunity through the course of the day for me to actually . . . do stuff. I actively contribute to the development of the product. There’s a 15 minute status meeting each day with my team, as part of Scrum, which serves a clear purpose. Its brief and done standing up. Other than that, its not uncommon for me to go the rest of the day meetingless — and its an absolute joy.

It is a joy because I truly feel productive. I feel like I’m making a difference at HubSpot. This really came home for me today when I re-skimmed Marc Andreesen’s Guide to Personal Productivity. Not only do I try to follow his index card trick, but I fell into his suggestion to not keep a schedule. Now I don’t do either of these things completely, but I’m almost entirely in control of my day now. I can focus on the things I think are most important for my job and for HubSpot. Not what the other people need and want. And it is incredibly satisfying.

2. Email.

With a modern startup, I have left the tyranny of the Lotus Notes/Microsoft Outlook inbox behind. Once I adjusted to the gmail threading approach to the inbox, my efficiency with email skyrocketed. Whereas previously I had frequently been declaring email bankruptcy, now I’m in the free and clear with my inbox by 10AM. I shoot for inbox zero and get there occasionally. But more importantly there isn’t the nagging feeling of hundreds of unknown, unread emails lurking on my machine. Again, the email isn’t exerting control over me, I’m in control over it and its satisfying.

Photo credit from www.vectorportal.com

Three things I learned this week

While I wait for my daughter to fall asleep so I can go for another ocean side run in Gloucester today, I thought I’d jot down three things I learned this week at work at HubSpot. It was a busy week, with lots of new faces as the Performable team made itself at home in our offices.

1. No sacred cows. We’ve got two products now at HubSpot. They both have their strengths. The thing I’ve kept on reminding myself, as we begin to understand the two products and how we can bring them together is that we shouldn’t hold onto any sacred cows as we work to create the best product for our customers. We shouldn’t care if it came from HubSpot or Performable or neither. We can’t be overly attached to our own handiwork if its not going to be the best option moving forward. Its easy to get defensive in these situations.

2. Don’t forget that new people don’t know everything about you. I did my first customer webinar on Friday. I got a compliment or two on my ability to give a demo. It was like they were surprised I could do it. And it reminded me “Hey, most of these HubSpotter only know me as a product builder”. For 4+ years at IBM I was in product marketing doing things like creating messaging and scoping out demo scripts and getting on planes to give talks at trade shows and gatherings of customers.  These are all things I don’t typically do at HubSpot.  So don’t forget, no one knows your other skills if you aren’t a little pushy about using them (assuming of course you want to use them!)

3. Patience. Lastly, I was reminded of the merit of patience. Good things happen sometimes simply by putting your head down and working hard.

A Former IBMer on Gerstner’s “Who Says Elephants Can’t Dance”

Gerstner's Who Says Elephants Can't DanceOver New Year’s I read Lou Gerstner’s “Who Says Elephants Can’t Dance”, on the suggestion of Yoav “the bestower of nicknames” Shapira. It was a good read, especially interesting to me as I left IBM 6 months earlier. The IBM I joined was already post-Gerstner. So it was really interesting for me to read about the Gerstner era as I could see the long term changes he had imparted (and some of the things that didn’t necessarily change as much as he’d hoped). Three things that stood out:

1) The Mainframe. Gerstner centers much of the narrative around the break from complete reliance on the mainframe business. My first job out of school was at Kenan Systems, a company focused on delivering a UNIX-based billing system to telecommunications carriers. It’s whole business was staked on replacing mainframes. And I never ever interacted with mainframes in school — we had all sorts of UNIX machines filling up our computer labs in school. By the time I joined IBM as part of the acquisition of iPhrase, IBM put us in with the “distributed” software business, in Information Management. We were completely separated from the mainframe business, for the most part. We executed our business with a set of practices and set of salespeople that were completely separate. Honestly, the mainframe business at IBM was like an entirely different planet to me: different salespeople, different licenses, different SKU’s (even for the same product), different release cycles.
So to read that the IBM that greeted Gerstner was 100% mainframe focused was an eye-opener. Really, the IBM I worked at was much much different than the IBM that greeted Gerstner in ’92 — heck, the software group didn’t even exist then.

2) The Focus on Competition. Gerstner, in the book, frequently talks about pushing the company to focus more on the customer and the competition. Gerstner hammered on about focusing on beating the competition — a mindset that apparently was not prevalent at IBM at the time. The piece about the competition really struck me because focusing on the competition was prominent in a lot of the business process templates we needed to follow (DCP’s for you IBMers out there). It almost felt over-emphasized whenever I was going through the investment approval process at IBM — and now it makes sense. Gerstner wanted it there when those business processes were presumably developed.

3) Executive Assistants. The description of executive assistants at IBM cracked me up, in part, because my manager at IBM took a turn as one. Just seems like a concept from another time and place. It wasn’t totally excised.

What did you think?

Giving up Multi-Tasking in 2011 (and other resolutions)

One of the things that bothers me (especially as a degenerate sports fan) is when folks make public predictions, but then never really follow through on assessing those predictions. So as I set out to make a couple of public New Year’s resolutions for 2011, I’ll first look back on my 2010 resolutions.

I made 2 big ones for 2010. I mostly proclaimed these to myself:

1) Run 500 miles in 2010

2) Find a new job inside or outside IBM

I tracked my progress for the running resolution at daytum.com/joshpayne. As you can see (if you check out that link relatively close to the posting day for this entry), I fell short by 131 miles. My modest goal, having never run consistently for an entire year, was to run 10 miles a week, for the entire year. Thus the 500 miles goal.  Though I missed the goal, I was generally pleased with how I did. Tracking my progress publicly on daytum.com helped to motivate me (its linked from my twitter profile). I ran consistently throughout the year, used my new treadmill a bunch but was done in by two relatively unforeseen factors: a flood on my property that left me with a big cleanup project for over a month and time management challenges once I joined HubSpot back in June.  I found that I wanted to make sure I was doing a good job at HubSpot at the cost of running, for the first month or so of employment. Once I got comfortable in the new job, my new routine and my new responsibilities, I worked running back into my life. Those two factors cost me 100 miles or so. And then a slight knee injury in mid-December accounts for the rest of the miss.

Finding a new job? I did that one. Though I didn’t really tell anyone about that one at the outset of the year, for obvious reasons.

So what’s in store for 2011?

1) I’m going to renew the 500 mile pledge and continue to track it publicly on at daytum.com/joshpayne. I would have liked to up the ante a bit, but given that I missed by over 25% in 2010, I’m going to keep my quota at the same level and hope I exceed it this year.

2) No multi-tasking. I recently re-read an article on the HBR blog that accounted for all the negatives around multi-tasking. Basically, my take home from the article was that your brain does one external thing well at a time. Doing two at the same time seriously impacts the quality of execution of one, if not both.

This observation definitely resonated with me, as multi-tasking at IBM was a way of life. Every day was filled with simultaneous execution of conference calls, email responses and instant messaging. I was on 6 hours of conference calls every day. Pulling off this resolution would have been really hard while at IBM. But I’m optimistic that I can pull this off at HubSpot as I have many, many fewer meetings and almost all of them are in person. No more tapping on my laptop in a meeting unless that work is directly related to the meeting.

I want to try to improve the quality of the primary thing I’m doing. And if something is so important as to be my “primary” task, I should give it 100% focus.

But this resolution will also carry over to my personal life. I already stopped talking on the phone while driving. But I’m going to give in less to the temptation of the information available on my phone at any spare moment. So no more checking email while “playing” with the kids. Or checking twitter while “watching the kids bathe”.  I think my engagement in the primary activities (i.e. spending time with my kids) will be better for both me and my family.  And no more reading while watching the game. I either wasn’t enjoying the game or I wasn’t processing the information in the book. Or both.

(and for the record, the following don’t count, by my arbitrary definition, as multi-tasking: listening to music while driving, listening to classical music while working, watching TV while running on a treadmill, singing while in the shower).

Now I’m not sure how I can effectively track my success at this second resolution (any ideas?), but I’ve already found it challenging and fulfilling to attempt to keep.

What are your resolutions? And how are you inspecting your results for those resolutions?