TDD (Test-Driven Development) is oft-used in Agile development shops. It involves coding up a test that will allow you to see whether your production code will return what you think it should return. The trick is, you code this test first – before you even start on your feature code.
The idea is that TDD reduces bloat within code, as you spend the time to define exactly what you expect the feature code to do up-front. TDD also helps you to write less buggy code, as testing is baked-in to the process as opposed to being dumped towards the end of the sprint.
In developing product features, Product Owners can learn from this technique. How? By working out how we will understand if our feature is being used before we even start building it. We could call this Analysis-Driven Development (ADD), though this is undoubtedly a terrible name.
Why is this important? Well, having worked almost exclusively with Google Analytics as my analytics tool of choice, I know that it is not well placed to capture information on user activity or usage. It isn’t very good at telling you what people actually did on your website, particularly if they are interacting with elements in-page. GA wasn’t designed to do that, and efforts to improve it in that area haven’t really worked thus far.
If, like me, you don’t have a Mixpanel or a Kissmetrics package, you are going to have to create a hack in your GA code to allow you to track the usage of your new feature. Normally this will involve setting up GA Events and Custom Variables in on-click JS when you are actually coding your feature. (How you actually do that is another post altogether.)
If you do not take this step in advance – and I’ve been guilty of this in the past – you’ll be asked how your feature is performing and you won’t know. Bad Product Owner. You’d have to go back to that feature in a future sprint and get your on-click JS added. By then, it might be too late; adding the ability to analyse the usage of a feature often won’t be as business-critical as building it in the first place, so you might struggle to justify getting this little piece of work into a future sprint.
So take the time to figure out how you’ll answer the question “Is this working?” in advance. You’ll save yourself a lot of pain when your gaffer comes a’ callin’.
An aside to end:
Dear analytics sales guys,
A must read presentation, not just for Product Managers, but anyone who manages PMs or who are stakeholders in product development environments (read: HiPPOs).
Discusses the importance of a cultured based on learning and the disadvantages that can come with “knowing when something will work”.
Take it away Ms. Cindy Alvarez:
Excellent, excellent, excellent talk.
The crux: the quality of your app or service doesn’t matter, nor does the marketing. It’s the ability to make your users feel good about themselves, the ability to make your users badass at whatever they strive to do (and that’s not just using your app, there’s a bigger goal), that leads to success.
“…this is what we want to compete on. The user being badass. This is the fundamental way to think about it. People aren’t using the app because they like the app or they like you. They’re doing it because they like themselves. What are you doing to enable more of that? …whatever anybody says, everyone wants this. So this is one of the most powerful experiences that we can give people.
…now that we know that recommendations are driving everything. They tell their friends not because they like you, but because they like their friends.”
“You should take extraordinary measures not just to acquire users, but also to make them happy. For as long as they could (which turned out to be surprisingly long), Wufoo sent each new user a hand-written thank you note. Your first users should feel that signing up with you was one of the best choices they ever made. And you in turn should be racking your brains to think of new ways to delight them.”
Why don’t more people do this?
“…a lot of of startup founders are trained as engineers, and customer service is not part of the training of engineers. You’re supposed to build things that are robust and elegant, not be slavishly attentive to individual users like some kind of salesperson.”
“Another reason founders don’t focus enough on individual customers is that they worry it won’t scale. But when founders of larval startups worry about this, I point out that in their current state they have nothing to lose. Maybe if they go out of their way to make existing users super happy, they’ll one day have too many to do so much for. That would be a great problem to have. See if you can make it happen. And incidentally, when it does, you’ll find that delighting customers scales better than you expected. Partly because you can usually find ways to make anything scale more than you would have predicted, and partly because delighting customers will by then have permeated your culture.”
You could easily replace startup with business, in this quote:
“I have never once seen a startup lured down a blind alley by trying too hard to make their initial users happy.”
“The feedback you get from engaging directly with your earliest users will be the best you ever get. When you’re so big you have to resort to focus groups, you’ll wish you could go over to your users’ homes and offices and watch them use your stuff like you did when there were only a handful of them.”
Image sourced from Treefiddy.
More actionable gold from the team at Conversion Rate Experts: