the perfect product balance makes the user both love and hate the experience.  the love comes the way the product solves the user’s problem and the way it makes them feel in the process.  the hate stems from the love, because by loving the product so much the user wishes it did even more.  any place in between is product ambivalence -- a no man’s land where projects and companies die.

perfect product pacing starts by solving a clear problem and shipping a simple first version of the product, only moving on and building more when the love and hate are sufficient and growing.  you start by having a meaningful first product, but as as reid hoffman, co-founder of linkedin and now vc at greylock, says, “if you’re not embarrassed by your first version, you’ve waited too long.”

too often an inexperienced founder will hesitate and struggle to get that alpha or beta out the door because they are tuning and building in fear that the current version isn’t polished or doesn’t do enough.  even experienced but undisciplined product managers will make this mistake, bolting on too many features without justification.  the key is to have an early thesis of why specific users want what you’re building and set out to prove this with as little code, development, employees, and cash as possible.  

this is the tact i took with airbear.  for sure early brainstorming and mocks crept towards a bulky v1 product, but i ultimately got it down to providing one clear value prop -- simple breastfeeding logging that lets parents know how that day’s feedings are going.  users noticed this and responded.

over 10,000 feedings later, positive reviews, and lots of love were also met with plenty of criticism.  what about bottle feeding?  why can’t i see the history?  seeing x or y data would be useful? can you add alerts?  this level of hate and wanting more not only showed me that there was an audience for airbear, but also showed me what i should work on next.  

you know you’re on track when you get angry feedback because that never comes from ambivalent users

arguably the greatest value this diligent method of product pacing provides is not having to go back and rework or delete old, stale features.  probably half of my day job these days is stripping out old features or irrelevant functionality that was built too soon and without justification.  des traynor, co-founder at intercom gives a great talk that compares two products.  one is a simple product that sees its competitor with tons of features and thinks ‘we need to add those’.  meanwhile that bloated product sees the simple one and thinks ‘i wish we didn’t have all these features, which are hard to maintain or that no one uses’.  

beware of product envy and build only when the time is right and the love and hate buckets are overflowing.  some of the best products today did that, even with millions of venture capital in the bank.  nothing shows prudent product pacing quite like the time between launch your iphone app and android.

if people love your product, after around the first few dozens of users you will start hearing requests for android.  these four companies clearly had the love factor, but they still waited on average for almost a year and a half to launch on android (and you can be sure that a lot of hate was piling up during that time).  if you’re curious how other great companies progressed and paced, there’s a cool site that lets you explore their timelines in more detail --

part of being a release note connoisseur means i also spend a lot of time looking through version history.  how, why, and when app updates are pushed tells a lot.  granted big mega corps like facebook or twitter are on a bi-weekly cadence of ‘minor improvement’ updates, but the early days of an app show the most drama.  big new features come out after a quarter or two of listening and talking with customers.  these can be the hardest months as it’s easy to just want to keep shipping new stuff.  but it’s when you have hundreds of users (as opposed to millions or billions) that you have the freedom to both wait and be bold.  

code cleanup and performance stuff aside, resist the temptation to ship new stuff. wait to see not just how many people are using your product but also how they are using it (which could surprise you), and by all means focus on growth.  that’s the road i’ve been on since launching airbear in february, and i’m excited to announce a long awaited update in the itunes app store.  

with the last airbear update, we are now just at step #2.  if we’re going to get to step #3, that’s going to take even more hard decisions about product pacing.  they may have the same number of wheels, but a bicycle is far more complex with far greater potential.

what step is your product on?

Authorjonathan hegranes

users can both feel how much care you put into a product, and how much care you didn't put into it.  this is often why big companies can't win because they have to scale.  or at least they think they do.

actually doing things that don't scale is difficult in practice, but your users will notice the difference and feel the love you put in and the time you took to make everything just so.  a great example of this is acompli versus inbox, wherein you have a small startup trying to make a great email app and inbox, which is google's latest email evolution.

i'm actually a fan of inbox and use it for my personal email on my laptop.  lovely animations combined with easy navigation make it wonderful, except that google refuses to do things that don't scale.  

in a day where i took both an uber and lyft, google inbox has put these in different buckets.  you'd think they would take the top 50 or 500 apps vendors and create specific rules for them.  manual, yes.  tedious, a little.  but perfect.  your email app, especially google, should know the top 100 finance companies, top 100 travel companies, etc, etc.  if you want to algorithm results after that, fine, but get the fat part of the curve exactly right.

meanwhile acompli has a better 'focused' inbox than google's priority inbox.  it recognizes actual people better, while also pushing aside newsletter type stuff that truly isn't priority.  just guessing, but i'm assuming a lot of this was done through very inefficient means.  at least at first, while they were ramping up.

the result was microsoft bought acompli for $200 million, and to microsoft's credit did not undo the magic.  they kept it open, kept it beautiful, and didn't make it too outlooky.  i'm still getting used to having outlook on my phone, as i hadn't used it for a decade, but it's still the best email/calendar option i've found on the iphone.  i just hope they keep putting the same care into the product.


Authorjonathan hegranes

six months ago i became a dad.

six months ago i started coding.

today i’m announcing air bear! 

you can read all about air bear on our medium post 'babies are hard' about how we’re helping new parents with feedings and providing a little sanity along the way.  or just go straight away to download the app :) 

 this is a story of how air bear came to be.

going back to last summer, apple had just announced swift, my friend dorian was starting a #codeaday challenge, and my wife was about to give birth to our baby girl.  together, these were the beginnings of what has become air bear.

anyone will tell you that i’m a sucker for anything new (i.e. chewing new cinnamon-roll gum as i type this), so apple’s new programming language was already enticing.  swift is the heir to objective c, which had been around since the early 1980s. pretty much every app on your phone today is built on objective c, but just comparing some of the syntax and features of swift vs objective c and it’s really quite beautiful. and from my perspective (a total noob), more intuitive.

coding has never been my day job, but always something that i’ve tinkered with. i’ve taken a few ruby classes and enjoy fiddling around with different technologies, but doing the actual building was a first for me.  it’s a skill i wanted to start developing for a number of reasons, as it helps me think about and understand products at a much deeper level, but it’s also a necessary skill if you actually want to be able to implement ideas on your own schedule.  as @fakegrimlock says, ‘if you not code, you not understand code’.

from "how to startup" v0.5 by fakegrimlock

figured i better get harper learning git at an early age.

figured i better get harper learning git at an early age.

so between swift and dorian, my brain was in the right space. harper -- our daughter -- was the inspiration.

one of my favorite posts by paul graham is ‘how to get startup ideas', where he says to work on a problem you have, and my problem at the time was the freshly minted baby that would wake up every few hours to eat.

we had taken baby classes, read books, etc, etc, but as this was our first kid, we didn’t know what to expect and i quickly noticed some repeating themes.  there was the question we’d ask 10x a day -- “is it time to feed the baby?” and that was topped by the number of times we’d wonder -- “is this normal???”.

naturally i looked to the app store for help.  

while there is invariably an app for everything... there is rarely a good app for anything.  

i pretty much refuse to use an app that doesn’t look good, especially the icon.  with existing baby apps, i had to throw that rule out the door right away.  while a lot of tracking and logging apps are functional, they are not easy to use, and certainly not fun to use.

so wishing i had a better way to know if our baby was eating well and when the next feeding was coming next, i set out to build air bear.

the first few months were all about learning.  learning what is a good feeding schedule.  learning what parents need and want.  and learning how i might actually build this thing.

after talking to a lot of parents, observing what hacks and systems my wife came up with, and armed with some base development skills -- it was finally time to start building.

making something simple is not easy, and the air bear concept had already ballooned into too much.  so the first step was narrowing down what air bear would be.  initial thinking was to track feedings, bottles, diapers, health stuff, and maybe even memories.  we may get there over time, but we needed a place to start and feedings are the most important.  it’s the thing mom’s track the longest and care about.  frankly something they’ll care about forever.  

but even after deciding to *just* start with feedings, i still ended up writing and later deleting more code than i needed.  i thought about collecting the birthday or birth stats like weight and height, which are useful but not totally necessary.  after distilling further and further to the root problem i wanted to solve, i got down to a what i think is a beautiful and simple minimum viable product.

i love this tweet by @manicho about a good mvp and hopefully air bear is closer to the second row than the first --

so this version of air bear in the app store today is the skateboard you see at stage one.  and what stage two will be is still to be decided.  i have a lot of ideas of stuff i want to build and new features i want to incorporate, but i’ll largely be looking for feedback from early air bear users.  what they love, what they hate, and what they want to see next.

please go download air bear on the app store today .

  (while you’re at it, please give us a 5-star review :)


(while you’re at it, please give us a 5-star review :)

and if you know of any new parents or those that are expecting, please do introduce them to air bear.  i’d love to hear their thoughts and feedback.  leave a comment below, or shoot me an email <> any time if you have any ideas for the app, for parents, for anything.

lastly, so many people to thank.  my wife has been amazing and supportive as i asked her *lots* of questions about breastfeeding, and super patient while i spent early mornings and late nights working on air bear for the last few months, especially when i was grumpy because there was some damned bug that i couldn’t yet figure out.  aaron who as been great to work with, kept me in check, and who designed the amazing air bear logo!  throughout the process, lots of friends have been awesome with feedback, support, and making really cool introductions to fellow new parents who might want to use the app, or to baby and lactation experts that have shared their wisdom into what nursing moms need to hear.  thank you <3

and there's also been so many amazing technical resources (besides stackoverflow) and experienced people that have helped along the way.  just a few of my favorite new people -- whether they know it or not -- are

@jonkawa, who provided some unique wisdom along the way.

@mengto, who is a design and animation magician.

@jamztang, who writes killer stuff on ios.

 & @awolnation, which has become my favorite early morning coding music.

Authorjonathan hegranes

top-down or bottom-up is a classic question with many potential contexts.

how do you model your company?  without question, bottom-up.

how do you view economic policy?  already the answer gets more gray and depends on personal feelings.  which way you lean will direct your answer.

how do you display a feed?  this question doesn’t seem to have a definitive answer and it’s the one that got me diving into this no mans’ land of product philosophy.

i have to bash twitter from time to time because it sucks at so many things (their persistent notifications problem befuddles me).  yet, twitter is still one of the first places to go to see “how did they do it”?  and twitter is the epitome of the top-down or bottom-up question.

the twitter new feed is top-down -- with the most recent posts at the top.  yet in the very same app, they use bottom-up for direct messages -- with the most recent messages at the bottom.

whenever using any product, i love to ask the question of “why did they do this?”  and i find that the answer usually falls into one of two buckets:

  1. genius product insights from amazing design, ux, and customer involvement

  2. copying someone else

the problem with copying is that while you know it works (at least you hope it works since at least one other idiot did the same thing), you also have no idea into the why.  you don’t know if that was done for legitimate, customer-centric reasons -- or simply because that company shipped it that way for whatever reason, or lack thereof.

after going through my phone, the one trend i can see that determines top-down or bottom-up is what i’ll call “purposeful interaction”.

if the product is simply displaying new content that you’ve (implicitly) subscribed to or followed, then it just flows on top…  examples being:

  • twitter (news feed)

  • podcasts

  • instagram

  • soundcloud

  • email

if the product is more like a dialog, then every new message goes to the bottom… examples being:

looking at these examples, it does make sense for purposeful interactions to be bottom-up -- because you want to see the last message you're replying to when your keyboard pulls up.

of course, there are products that are starting to evolve beyond a simple top-down or bottom-up.  facebook is top-down, albeit highly filtered and algorithm-laden.  but then there’s examples like disqus, quora, or reddit which try to elevate the best content to the top -- whether that data is two seconds or two years old.


Authorjonathan hegranes

without question, my favorite part of any product is the feeling you get from using it.  sometimes this means an extra feature or a cool animation.  sometimes it’s the fact that nothing happens at all.  sometimes it stems from not letting you do something, in a good way (i’m looking at you, twodots).  sometimes it just makes you feel good.

the beauty of this feeling is that it endears you to the product in a way that cannot easily be copied, and more importantly ties you to that product for much longer time frame.  

i’ve long admired this in products… back when i worked at disqus, i did a thing at an all-hands where i jokingly trademarked the “point of tap” as *the* opportunity.  and a lot of my recent thinking about the right interactions has led me to dive into this more deeply.

we all do the same things every day, whether it’s buying a cup of coffee or downloading a new app or logging into a site.  and all it takes is a little bit of magic to pretty much forever connect with that person for life.

philz coffee does this by not only making you an amazing cup of coffee, but when they hand it to you, they say “make sure it’s perfect”.  how perfect is that?

headspace does this with the absolute perfect loading animation…  not to mention their videos are spot on.

taking lunch as an example, there are variables that lead up that moment where we order or take our first bite.  and then there’s how we feel afterwards that is more of a direct correlation of the product / service we just consumed.  but in the middle is a no-man’s land of either magic or blah.  

we don’t always realize the blah, but you’ll respond to the magic -- consciously or subconsciously with your heart, mind, and wallet.

the other fascinating thing about this is the same process can still feel really different.  i’m still not sure why this is, but a commit to github via the terminal just feels better than using the github app.  buying a taco after waiting in a long line feels different.  getting surprised / amused at something mundane feels really different.

alexis ohanian and tim ferriss (on tim’s podcast) go into this a bit, and kevin (aka, best twitter handle ever) had some really good examples in sam’s startup class.  #mustwatch

i realize this (magical ah-ha state of utter stupid bliss) is both really hard but really easy to do.  in the end, it’s a game changer and something i’m striving for / focused on intently.

Authorjonathan hegranes

my last three phones have been android, and i’m a very happy, satisfied user -- even proponent of android.  but i’m still switching back when they announce a new phone on tuesday.  basically what aaron levie said…

my biggest gripe about ios / my biggest love of android has been about choice.  i wanted -- and still do want -- to be able to download whatever app i want, to choose my default apps, and to have the kind of freedom we’ve come to expect from our laptops.  software is eating mobile, and this is clearly the direction of both platforms, albeit ios at a slower pace.

but for too long i’ve probably been wearing android-colored glasses.  every piece of data i saw, i would conclude that it benefits android.  at least until benedict evans (subscribe / follow / read everything you can that he puts out) slapped some sense into me.  he posted this chart on global handset sales…

to which i concluded that android was the way of the future.  he quickly set me straight.

he's right that you have to do both, eventually.  but where to begin?

the crux of my decision to go iphone was really about app development.  i don’t think it’s possible to design for a platform you don’t use each and every day.  mobile is where i spend the bulk of my team these days and it’s time to make the switch.  hopefully a few blog posts down the road, you’ll *really* see why.

andrew chen wrote a great piece recently about why android needs a billion dollar success, and he has some great ideas on how to make android-first a reality.  depending on your market and traction levels, android is a natural evolution, but it’s not the starting point in most cases.  the one exception is when your app is google-dependent or one of the banned topics on the itunes apple store -- such as bitcoin.  but per benedict’s point, apple is still the most fertile ground to launch most apps.  

i still believe the direction is moving in android’s favor, and some of apple’s recent decisions -- such as backing patent trolls -- has turned off a lot of its most fervent supporters.  but my multi-year hypothesis doesn’t have much relevance on a near-term market decision.  thus, you’ll find me on tuesday constantly refreshing the apple store page, waiting to place my order for an iphone 6.


Authorjonathan hegranes