Marketing 101: Always Include A Call To Action


Not having a CTA is like a local car dealership paying for a TV ad without the “Come on down to ______ and see our great deals” at the end.

I like NatureBox – they mail you snacks each month.  I bought a subscription for my wife as a Christmas gift because she works from home and likes to snack between meetings/calls.  They have good food (although I’m not sure it’s so healthy).

I was excited to see they’re now offered in select Target stores – got a coupon to get a free bag in our last NatureBox.  I also got the above flyer to refer a friend.  I would definitely have done it, but there was no Call To Action – no “log onto, visit” – nothing.  Now I know that I probably need to log onto the site, but at this point, I’ve lost interest.

Key lesson? Include a CTA on all marketing (especially really expensive print materials!) and make sure you’re providing clear, detailed instructions if there are many steps needed for the person to take the action you want them to take.

Want a free analysis of your current marketing campaigns? Drop me a line.


Don’t Rebuild Your Product From Scratch


Rebuilding a product from scratch is like upgrading to the latest model of your car – it happens all at once, and until you do it, you’re still driving a beat up jalopy.

I see it all the time.  People spend years building a product and then throw it away to rebuild it from scratch.  It’s one of the most expensive SaaS product mistakes out there, especially if you’re planning a “big unveil” – a single day when all users/customers will switch entirely from the old version to the new version. Here’s why it’s not a great idea to throw away an entire product and start over:

The New Product Can’t Be Sold

I’ll use the new car model analogy above.  Even the slickest car salesperson couldn’t sell you a car that didn’t have doors, or an engine.  Think about it: you’re working on a new version of your product but it’s not quite ready because it doesn’t have feature X or Y yet, so you’ll never sell it.  Maybe you can demo parts of it, but if it’s not all done, customers won’t (and can’t) buy it.  So what value has your new product generated?  None, until it’s ready for prime time.

It Takes A Long Time To Rebuild

This may sound obvious but if you’re building a new version of your product you can’t take features that your existing product supports away, unless they’re not used at all.  (and even if they’re only used a little, you’d have to figure out a transition plan for the users who are using them).  Assume it will take about 50% as long to rebuild each feature as it took to originally build it.  So if you built your existing product in 2 years, a rebuild will take a year.  That’s a long time to not have new sales. (I’m assuming you’re rebuilding because the current product isn’t selling).

Feedback Is Hard To Get

Maybe you have a really engaged user base willing to beta test your new version (or whatever’s built so far).  But probably not – maybe you’re disciplined and are running usability tests along the way.  But that’s not with your existing users, and it’s not with their own data.  The point is this – in a world where you’re betting big on the new version, not having a way to validate your new product from existing customers/users is really risky.  What if they don’t like it?!

Migration Is Painful

In the wild, migrations are ugly – water buffalo get eaten by lions, birds die flying south for the winter, etc.  You’re gonna lose users along the way.  Plus moving data around is hard – especially if the data doesn’t map exactly to the new feature set.  (“well, what should we do with THIS user data?  It doesn’t exactly fit into our new version properly.”)

An Alternative Approach

So what’s a better way to upgrade your product without a “big bang” release? Unlike cars, software can be updated slowly and doesn’t require that “all at once” upgrade.  You can update each page in your web app, you can update the most important features in your mobile app.  You can take a much more Agile approach.  And I’d strongly recommend it.

Fix The Biggest Problem First

You thought you needed to rebuild for a reason.  Maybe Tech told you the existing product can’t support a new feature.  Or that the current architecture is brittle.  Or that you got a new team and no one likes / understands the existing product / code base.  All legit motivations to want to rebuild, but not legit reasons to actually rebuild.  Product should prioritize what single change would make the current product better.  Start there and see what you can do to address that issue.

Partner With Tech

This approach can’t be done without some help from Engineering and QA.  They’re gonna have to think of an iterative approach to get from what you have today to where you want to go, whether it’s a backend replatforming, a Service-Oriented Architecture, or a new front-end tech stack.  The ultimate question is what can we do in 1-2 sprints to start releasing parts of “the new product”?

See Immediate Value

Google Drive did a good job with this a year or two ago.  They wanted to revamp their product, but they did so iteratively and told users they could “Try the new Drive”

Try the New Drive

Great – users could still use the existing product, but they could also explore the upgrade and provide feedback.  Perfect for Google to slowly perfect the new version and eventually sunset the old one.  You can even default users into the new version, when you feel like the feedback suggests that it’s “good enough” – just make sure they know they’re looking at a new version, and give them the ability to toggle back to the old version in case they really like a feature that doesn’t yet exist in the new version, or just hate the new version (tracking how many users toggle to the old version and for what is a great way to gather data to know if you’re new version is ready for release).



How to Get More Mobile App Users

App makers who don’t optimize the adoption funnel are like car dealerships who still using the same marketing tactics as they did in 1980.

Let’s take a look at the standard adoption funnel for your mobile – the steps a prospective user needs to take to register for your app (or “adopt” it).  The funnel below has some made-up stats for the purpose of this post.  Note that the overall conversion rate is the product of the 3 conversion rates between the 4 steps (50% x 25% x 75% = 9.375%).


Step 1: Discover

This is all about building awareness of your app, and what your marketing team is probably focused on.  The more people that get here, the more users you will have.  But beware: you may not want to drive a bunch of people to this step before your funnel is optimized, as this is perhaps the most expensive step.

Getting People From Discovery To The App Store or Google Play


Channels like Google, Facebook, Twitter, and Instagram  are great for targeting and relatively cost effective as a starting point.  The call to action should drive them directly to Step 2 – your page in the App Store or Google Play.  You could send them to a landing page, but you’d be introducing another step in the funnel, which won’t help overall conversion. (but this might be worth A/B testing with your audience)

(Side note: I wouldn’t recommend non-digital ads (TV, radio, print) as a starting point because even though you’ll reach a broader audience to build awareness, you’ll lose a lot of people in the process of getting them to take out a digital device like a phone, tablet or laptop and come to your web site or search for your product.  Most startups can’t afford non-digital ads.)

Get press

If you have something unique to offer, tell the world.  But make sure there’s a story there for reporters.  To learn more, here’s a decent primer on writing a press release from HubSpot. Again, the call to action from the story should be to check out the app in the App Store or Google Play.

Hold events

If your app is specific to a city or region, or you’re initially targeting users based on where they live, holding events like launch parties might be a great idea.  The key is to make sure there is a good reason (like a raffle prize or exclusive feature access) for attendees to fly through the funnel and download the app at the event itself.

Generate referrals

Once you have a decent user base (or a very engaged user base), you can recruit them to help spread the word. Build a referral feature and/or program and make sure your users are incentivized properly to direct their friends and family to Step 2.

Step 2: View in App Store

Once a prospect knows about your app, they have to get to the page in the App Store to download it.

Getting People From Viewing The App To Downloading It

App Store Optimization

A lot of people discover new apps by searching the App Store or Google Play.  Just like you might optimize your web site to appear on the first page of search results (Search Engine Optimization), you’ll want to know that your app shows up at the top of the list when people are looking for new apps.  For more information, read this: Top 10 Ways to Optimize Your App Store Search Ranking and Presence.  In particular, make sure to use screen shots and videos to visually explain the benefits of your app, as well as a good description and solid set of (hopefully 5-star) reviews.

(There are a lot of great apps for creating beautiful screen shots to use in the App Store and Google Play – I like

Test your discovery techniques

Context matters – the way that the person got to the app store may very well influence whether she decides to download your app.  For example, if I ran an ad advertising “the best new dating app”, I’ve set a high expectation – if my app’s description, reviews and screen shots don’t also scream “the best new dating app,” she might not download it.  On the other hand, if my ad read “the hottest new dating app”, she’ll come in with a different set of expectations.

Small changes like these matter – track click through rates on your ads and periodically take a survey of what’s working and what’s not.  Ideally each ad has a unique URL that it goes to, so you can track the download rates on a per-ad (or at least per-campaign) basis.  For more on how that works, visit:

App Store

Google Play 

Step 3: Download

Once they get to your app’s page in the App Store, you still have to convince them to download your app. (Side note, this applies mostly to iOS apps – Android is launching Instant Apps, which lets a user download your app without going to Google Play).

Getting People From Downloading The App To Registering

Once someone has downloaded the app, there’s a good chance they’ll open it immediately, but if they don’t, you’ve significantly lowered your chance to get a registered user, unless you’re confident in what cue might later prompt them to open the app they just downloaded. (for example, with dating apps, I know that boredom at home is a prompt that gets people thinking about dating apps).

Talk To Users

Optimizing the conversion rate of people who’ve downloaded the app to the number of registered users probably requires some user research.  Ask random people in your target audience to download your app and talk out loud as they open it and look at your splash screen / registration page.  Look for clues on what might be confusing – what barriers / open questions are there that might prevent people from registering?   Should you hae a link to your FAQs on the registration page? Make sure to address the barriers in the next release of your app (which hopefully isn’t but a month or two away, if you’re using Agile).

Demonstrate Value Quickly

Ideally a prospective user doesn’t even have to register before getting some value from your app.  If it’s possible to let them explore a feature or experience the sweetness that is your app before registering, do it.  Then create a compelling reason for them to create an account after playing around (for example, maybe in a dating app you can let them see potential connections quickly and they register in order to start messaging people that look interesting).

Tracking the conversion rate between steps 3 and 4 isn’t hard – the App Store and Google Play will let you see how many downloads you’ve had during a specific time period, and hopefully you have some kind of reporting dashboard that tells you the date/time that new users registered so you can calculate this conversion rate.

Step 4. Register

Victory!  Nothing sweeter than a new user.  In a future post I’ll write about how the onboarding experience (AKA first-time user experience or FTUX) plays a critical role in determining whether new users continue to use your app.

Want a free analysis of your mobile user acquisition funnel?

Why A Generic Cover Letter Is Worse Than No Cover Letter

Writing a cover letter is a really good way to make your application stand out — few people do it. But don’t get me, the hiring manager, excited about a cover letter only to find something like:

Dear Recruiter, your company is really exciting to me. Here’s a summary of my resume, which you easily could have deduced from 15 seconds of actually looking at my resume. Please interview me.

The cover letters that really help your chances are way more specific to the role I’m hiring for (and yes, I can tell how much time you took to research the role and company). Tell me why you’re excited to work at my company. Tell me how your past experience would make you a good fit for the role (especially if you’re trying to transition into a new function). Tell me how you‘ve already talked to one of my colleagues — or even a former colleague.

Ultimately the point of the cover letter is to provide me with information I couldn’t have seen from your resume, and the most interesting information is why you’re interested in this role and why you think you’d be a good fit.

Why Production Is The Best Place To Do User Research

Not doing research in Production is like only testing a car with crash test dummies in a laboratory

Getting quality user feedback about your product is hard — it takes time to recruit users, prepare a study, ask the right questions, get people to answer honestly, and then summarize the results into actionable next steps.

But there’s no place as good as Production to get feedback. Talk to your users while they’re using their own devices (computer, smart phone, tablet, etc.) and most importantly, while they’re looking at their own account with their own data. Because there’s nothing like real user data to change feedback.

For example, with HelloWallet, we do a lot of testing before we release changes, but that requires us to either make up test data for user research purposes, or prepopulate prototypes / clickable experiences with fake data that inevitably is wrong for the person who’s looking at it. And they often get tripped up by that, throwing the study off on a tangent.

That’s not my 401(k) balance — I wish I had that much.

Well, I don’t spend that much each month on my credit card but am carrying more debt on it.

I’m not saying you shouldn’t test before getting to Production — you definitely should as it’s cheaper and faster than testing with your live app, but once you do release something, get back out there and ask people what they think when they’re using it in the wild. There’s nothing like that feedback.

5 Tips For Building Product Roadmaps


Managing a product without a roadmap is like driving off road.

April 2017 update: my thoughts on roadmaps have changed – if you’re working in Agile, be sure to read Why Agile and roadmaps don’t mix.

Not every product needs a roadmap. If the product is really young and you’re still trying to find product/market fit, don’t waste your time planning a roadmap that’s probably wrong. Instead, spend your time building what you think will sell and iterating based on feedback. (yes, I’m assuming you’re building your product using Agile because it’s 2016)

But if you have a lot of stakeholders (clients, sales, marketing, support, operations, etc.) who need to have an idea of what’s coming down the line, you’ll need a roadmap. Here are 5 tips:

1. Group changes into epics.

Ideally you’re grouping together changes based on the problem you’re trying to solve for a user. For example, with HelloWallet, we recently spent a few sprints focused on helping users decide how to juggle their savings and debt paydown goals simultaneously, since we knew from our user research that it was one of the toughest choices our users were facing.

The reason to group changes together is for efficiency sake. If every sprint is a hodge podge of user stories that cover a bunch of parts of your product, there’s a lot of context switching for everyone on the squad — design has to understand the existing UX and suggest changes, engineering has to touch different parts of the code base (some of which might have cobwebs on it), and QA won’t be able to prioritize regression testing scenarios since you’re changing things all over the place.

2. Prioritize epics based on KPIs.

A roadmap is nothing more than a listing of the things that you think have the highest likelihood of moving your KPIs (in particular, the $$$ KPI I discussed yesterday).

Prioritization is a science and an art. You can get scientific by creating a score card to evaluate epics on their likelihood to move different KPIs, or based on other factors. You can edit the weights of the different factors easily so that you’re scoring epics consistently.

example score card

The art comes in with a gut check of whether you’d actually prioritize epic 3 at the top of your list. Maybe you socialize the score card with your squad and get some qualitative feedback (“ugh, that?” from your favorite engineer or “oh, shit, that’d be killer” from your favorite sales lady). And you adjust accordingly.

3. T-Shirt size epics.

As a Product Manager, you should never make up timelines. Mainly because you’re not the one doing the work. You’ll need buy in on timelines. No one on your squad wants to feel like they are handed an unrealistic timeline and have to execute against it. Hence getting them involved in the process.

At HelloWallet and Morningstar, we use t-shirt sizes to get us in the right ballpark for an epic (it’ll never be very accurate). We start by writing the epic as a user story and getting a group of people together to estimate it — tech, design, product is usually a good starting point.

During estimation, a million questions come up. That’s why we write down assumptions to make sure we’re all on the same page in terms of scope. (“oh, what about this scenario?” — make an assumption about how to handle that scenario).

T-shirt sizes are as follows:

  • XS = < 1 sprint
  • S = 1–2 sprints
  • M = 3–5 sprints
  • L = 6–8 sprints
  • XL = 9–13 sprints

Once you have an estimate, get conservative and use the high end of the range. Assume you forgot about some part of the scope or that something you all thought was going to be easy will be hard. No one will ever complain if you execute on your roadmap faster than you said you would (well, I suppose the would if you ALWAYS executed faster). But they’ll really give you the stink eye if you’re late in delivering something they planned for.

4. Build a 12-month roadmap.

Don’t try to plan the next 3 years — it’s gonna be wrong. Just plan the next 4 quarters.

At Opower, we ran some stats and found that our roadmaps were really accurate for the next quarter, pretty accurate for the next two quarters, and almost always wrong after 6 months. That’s not bad — a lot changes in 6 months (especially at startups).

5. Get feedback.

Socialize your roadmap, especially with sales. If they shake their head, find out why. Is there something else they think would be more meaningful? Talk to other people in your organization, even ones who don’t work on your product or in your business unit. And in true Agile form, iterate the roadmap (once or twice). But don’t update your roadmap more often than quarterly. As you can see from above, there’s a lot that goes into the process. If you’re updating it monthly, you’ll never have time to execute on the roadmap.

Picking The Right Image To Spur Action


Yesterday I saw this ad on the train ride home. Now it’s been a while since I’ve dated, but I don’t remember many dates where I was tickling her neck while drinking tea. Nor am I sure that’s a dream date for girls.

My sad dating history aside, the real issue I see with this ad is that it seems to have nothing to do with how GrubHub can help me dazzle my date. It might have if it was a picture of two people eating some delicious food on a sofa while watching TV. Or maybe in a park eating…

And so ultimately GH failed to get me to take action by ordering dinner through their app. Instead I spent 2 minutes wondering what the design team (or agency) for this ad was thinking and then 5 minutes writing this post.

I’m all for real world imagery in products and ads since they get the audience to envision a scene (aspirational or realistic). But they need to inspire action, like this other ad I saw on the train.

The Only Product KPI That Matters

Managing a product without KPIs is like driving a car without navigation — you’ll never know if you’re closer to where you want to be, and neither will your passengers. (“Are we there yet?”, for your road-tripping parents out there)


Key Performance Indicators are simply metrics you use to measure the effectiveness of your product. They may sound simple and obvious but getting stakeholders to agree on what actions are most important to track isn’t easy. But doing so ensures alignment, which is really important, as I’ll explain in another post about using KPIs to generate roadmaps.

The Only KPI That Matters

The $$$ KPI: profitability, which can come in the form of “scalable revenue” or cost savings (or maybe both). If you’re not prioritizing your roadmap according to this KPI, don’t expect to be managing your product for long (even at a startup). But wait, what about helping users solve problems or reaching your company’s mission? Yes, those are definitely important but if you don’t have any users through sales, does it matter how great the user experience is or how much you want to change the world?

Other KPIs

I’ve found it best to have only 2–3 KPIs, including the $$$ KPI, to keep things simple (and to avoid prioritization conflicts when using the KPIs to generate a roadmap). The other KPIs should be related to the $$$ KPI, though — most likely leading indicators of whether you’ll generate more profit. These KPIs may change over time as you learn more about your business, customers and/or users. Maybe you think logins or email opens are the most important metric, until you realize that there’s a particular feature that’s really moving the $$$ KPI.

As an example, with HelloWallet, we use the Financial Wellness Score as a KPI — if we can measure whether we’re improving our users’ personal finances, we’re more likely to keep existing customers and win new ones.

Tracking KPIs

Monthly (maybe quarterly) is perhaps the cadence to track KPIs. Ideally you have a dashboard that’s updated automatically every night. But you probably don’t because it’s hard and there are a million other things that are more important (or are they?). Even if you have to manually update a dashboard, publish it somewhere so all your stakeholders can see it, and discuss the status of the KPIs regularly (including what actions can be taken by different parts of the organization to move the KPI). Otherwise you’ll never know if you reached your destination…