Monthly Archives: May 2013

Focus on Your Product, Not History

History isn’t written in the present.

While we are in the middle of change or struggling with adversity, we can’t always see the upside of the situation or an eventual positive outcome. All we can do is give our best effort, push forward, and leave the documentation to the historians.

Reading Marco Arment’s accounting of the Tumblr story, I can relate to how easy it is to second-guess decisions and have doubts about the future while in the middle of product development and funding issues. What stood out for me in that story was the intense focus of David Karp, the founder. He knew what was most important and made sure that other concerns didn’t get in the way. His focus was on his product.

As tech companies go, Tumblr already has a decent saga for historians to write.

Who would have guessed that Apple would be the most important tech company in the world from the perspective of 1997. It took the return of Steve Jobs—one of the most focused individuals to ever start a company—to resurrect the flailing corporation. Writing the story of Apple during their “doomed” years1 would have been a complete waste of time.

Every lengthy development cycle stresses individuals in a company. That’s because most of the feedback is in the form of bug reports and design criticisms. It takes a strong point of view to keep a product on track and push it out the door. It takes ignoring the premature writing of history and focusing on what’s important right now.

My team is in the process of developing MoneyWell for iPad. We just finished minor updates for our Mac and iPhone releases and those were incredibly difficult for me. Not because the development was tricky, but because I had to ignore requests for changes to those apps and focus on what we needed for our iPad version. It required saying “no” to customers and to myself over and over again.

It’s tempting for me to try and fix everything, especially when in my head I can see where our products will be in 12 to 18 months. It’s ego busting to field criticism for flaws that I know exist and know will be eliminated—later. I can’t defend my decisions today, but instead have to take the punches, apologize, and ask for a bit more patience.

I have to leave it for historians to decide if I was focused enough to produce excellent software. Time will tell if the choices I make today were poor, mediocre, or amazing. There’s no time for me to beat myself up for past mistakes, I have to give 100 percent of my energy and effort to my team and my customers through my product design today.

Living in the past opens me up to drowning in self-pity and time spent projecting any possible future is mental folly. I can only change what I’m doing right now. I can only make decisions for my next action. I can choose to see this as limiting or liberating.

Today I choose to be liberated and continue to improve our company and our products.


  1. Yes, I know that Apple will forever be “doomed” for some tech writers

Five Sure-Fire Ways to Sabotage a Release

In March of 2012, I gave a talk at NSConference 4 and lifted my kilt and invited attendees to learn how not to go about shipping a software product. Luckily for them I was wearing pants and what I lifted was a virtual kilt, but it was still a disturbing presentation.

I may or may not have made them stare at “Baby Hoctor”1 for an extreme amount of time.


My goal in airing my dirty laundry was to prevent other developers and entrepreneurs from making the same mistakes that I made. In case you missed NSConference and haven’t seen the videos2, here is a synopsis of that talk.

#1 Announce Features Early

Back in 2008, our customers were comparing MoneyWell to Quicken and asking for investment support. Not wanting to disappoint anyone, I innocently said, “Sorry, investments won’t be supported until 2.0.”

Boom. I talked about a product release that I hadn’t even started planning and I didn’t stop there. I talked about dozens of future features and didn’t even say they’d have to wait for a major release. At the time, it seemed innocent enough. Customers were asking questions and I was answering them to the best of my ability. I truly believed that I was shipping a 2.0 release in the next six to eight months, so why not tell them that they’d have to wait?

The problem with talking about functionality not in the current release sets expectations and distracts from marketing what’s already wonderful about what you’re selling. All you’re doing is diminishing the product you’re selling. You are also making a promise to your customers that you may need to break down the road if priorities change (or Apple implements new OS features that force your hand).

#2 Cannibalize Features for Free Releases

Being a people pleaser, I fell victim to the trap of feeling guilty for not giving my customers more features. No one was yelling that MoneyWell was horrible, but in my head I had a vision for the functionality that I wanted in the 1.0 release. This vision caused me to steal features that should have been in a paid upgrade and release them in dot releases, which were free.

MoneyWell 1.4 could have easily been a 2.0 release. 1.5 could have been a 3.0 release. Let’s not even talk about 1.6 and 1.7—all free releases. I should have stopped at 1.1 (what 1.0 should have been), rolled my 1.2 through 1.4 features into a 2.0 release, and charged for it. That income could have been used to hire a designer and improve the quality of new releases. It would have been a win-win for my customers; instead I hijacked my marketing budget and stretched cash flow thinner than necessary.

By allowing my misplaced perception of value to get in the way of the business side of development, I cheated my customers out of better software. What I thought was generosity was instead a tradeoff of short-term features for long-term benefits.

#3 Rewrite All the Code

After four years of shipping free updates, work finally began on MoneyWell 2.0. The year before, I had hired Michael Fey to help me develop MoneyWell for iPhone and I added Danny Greg to our team to accelerate the work on our new release. Both these guys are sharp developers who were knowledgeable in the latest Objective-C and Cocoa techniques and ready to fix all the “old guy” code. I was embarrassed by some of my ancient code—written in my early days of Cocoa development—and quickly gave the nod to replace some of that code.

My lack of focus on code reviews and my desire to create the best MoneyWell possible made me vulnerable to rewrite suggestions, and some of the “old guy code” was actually pretty good. There were also external forces at play. At WWDC, Apple announced OS X Lion and I decided that we could remove a ton of custom code by ditching support for 10.6. This wasn’t a bad decision, but it was painful to discard nearly six months of work. If I had planned a more focused 2.0 release, we could have shipped 2.0 before WWDC11 and avoided much of that pain.

#4 Do Documentation Last

Because my project plan for MoneyWell 2.0 lacked focus and included so many features, this release was running months late. By February 2012, I felt pressured to ship it quickly even though there were bugs and incomplete features. But the most embarrassing mistake was the total lack of documentation. I had no 2.0 manual, no videos, no online help—nothing. I relied on a short in-app guide to train new customers and assumed our simplified interface would be easy for existing customers to adapt to the changes.

It was a huge mistake. New customers were confused, existing customers were pissed, and I was depressed. Because I had spent months of development time using 2.0, my understanding of how much had changed was skewed—MoneyWell 2.0 was old hat for me. There was so much to be proud of in our new release, but no one knew about those features. All people knew was that lots of things had changed and some features were missing.

A bigger issue with waiting until the end to write documentation was the loss of customer perspective. If I had to explain features with documentation as I was writing them, I would have seen several flaws in my design logic. There were components of the new spending plan that I would have scrapped if I had tried to explain them to a non-technical audience. I was seeing my app completely from a developer viewpoint. What a disaster—I had let everyone down.

#5 Extend “Crunch Time” for Months

This project was full of blind spots for me. I wanted my old code cleaned up, which caused me to give thumbs up to unnecessary rewrites. Features that seemed “almost done” were weeks away from completion. The project changed directions a couple of times with changing the OS target and feature creep. I started the development crunch time before WWDC and we didn’t ship for eight months. It’s okay to push a team for eight days or even eight weeks, but eight months is insane. Completely. Insane.

The Right Way

So what’s the right way to run a software company?

  1. Keep your mouth shut. Don’t talk about features until you are ready to ship. Save them for a teaser video and use “leaks” for marketing.
  2. Don’t give away software. You deserve to get paid. Customers deserve to have you around to support them for years. Hang on to features for major paid releases and give you and your customers a great future.
  3. Never rewrite functional code. If it works, don’t touch it. If it works, don’t touch it. FOR THE LOVE OF PETE, DON’T TOUCH IT!
  4. Build software and documentation together. If you don’t have time to write documentation, you have too many features. Writing how software should be used while writing the code will make your code better. Make time for it.
  5. Minimize crunch time. You and your team have limited energy. Long days are fine at the end of the development cycle, but not for months. Cut features if you need to ship faster. Don’t kill yourself or your team.

I made way too many mistakes for a guy that has been doing this for over three decades. Learn from my errors and ship awesome software. I’m trying to do the same.


  1. Blame Phil Letourneau
  2. I highly recommend buying the videos


It’s both a blessing and a curse. The disease that drives me to create software, has cost me GPA points and bank account dollars.

I’ve always struggled to let go of a problem. Even as a small kid, I would take apart electronics when they didn’t work as advertised and try to fix them—no skills, no training, just a basement full of rusty old tools and hyper focus. My parents weren’t happy when my projects failed to go back together as easily as I took them apart, but that never stopped me.

I always felt confident that I could fix anything. Even as a teenager, I decided that I could fix the busted two-speed Powerglide transmission in my ’68 Camaro. The one in my broken down Bel-Air of the same year was similar. How hard could swapping linkage and transmissions be?

My first attempt broke the same front pump gear that stopped my Camaro from moving in the first place. My second attempt was better, but my pretty blue Camaro only went in reverse… slooowly. The third attempt was spot on (although I was annoyed having to replace the transmission fluid again). With only a minimum wage job at Taco Bell, I had much more time than money (the Bel-Air was a $150 car and the Camaro an expensive $800 investment) and plenty of incentive to focus on fixing my wheels.

In college, I used to spend hours camped out on a computer terminal until they kicked us out at midnight. A few of us Computer Science (CS) majors convinced the engineering students that we could help them with their programming projects in exchange for access to their exclusive room of five terminals. The big terminal lab was always full of “lowly” Data Processing students working on their clumsy COBOL code, but having this private space to work fueled my obsession.

Even away from the terminal, I would churn on a software problem. I’d wake up in the middle of the night with solutions and have to write them down. My goal was to have my project submitted early with extra features—I wanted to be the best programmer no matter what the cost. Consequently, other classes suffered if they happened to require my focus during a development cycle. Being hyper-focused made me a top CS student with an average overall GPA.

Fast forward to today and my ability to hyper focus has been a great asset for my software design. MoneyWell would not have been as innovative if I took a casual approach to creating it. The problem is that selling software isn’t all about the code; you need to promote it, document it, and manage a company infrastructure.

Unfortunately, I’m only hyper focused with things that I like doing and I like doing the software design the most. Structuring a company is easy enough—I’ve done it several times over the past three decades so I can knock that out without much focus. Accounting, payroll, taxes, and corporate paperwork are boring as all get out, but I can outsource those tasks. It’s the promotion and documentation that tends to lag with me.

Now I love a great looking website and clean, clear documentation, but both those jobs get pushed off in favor of improving the code. I should spend more time on both, but once the bare minimum is done, I lose focus.

Marketing is my real weakness. I think I’m good at marketing, but it’s so painful to do sometimes. The most difficult part is promoting my products when I’m not 100 percent happy with them. Even if they are better than many of the competing products, I struggle to write ad copy. I start and then think, “I could fix this portion of the code and then I’d really have something to brag about.”

It’s a sickness. I completely admit it. But I am working to improve.

The next few rounds of software releases will be the proof that I have some control of this problem. The prospect of higher sales revenue due to better marketing is decent incentive, but that means I have to step back from my coding tools to make it happen.

We make great software that has dramatically improved the financial futures of thousands of our customers, but if people don’t know our software exists, what good is all that engineering effort? I have to keep reminding myself that marketing doesn’t just happen. It requires me or someone else in my company to take action. Apple may give us boost now and again, but that’s just one small piece of the marketing puzzle. I have to stop pretending that the next release will simply be so wonderful that it will get rave reviews by every news source and talked about by every blogger. Promoting software requires planning and needs someone to execute those plans.

Speaking of which, I have new releases of MoneyWell and MoneyWell Express that are nearly ready for App Store submission and I haven’t written press releases or updated the documentation yet. I’d better focus on that.