Hacker News new | past | comments | ask | show | jobs | submit login
How ‘Critical User Journeys’ can help a product take off (medium.com/initialized-capital)
194 points by wyndham on July 5, 2017 | hide | past | favorite | 34 comments



This is sound advice, but not new advice. A couple of things that jumped out at me -

Yes, yes, 1,000x when it comes to the importance of simplicity. It's far too easy to unknowingly distract yourself and your users from what is important in your product.

My criticism is that this pays very little attention to how important it is to get to know who the people are you are attracting at the top of your funnel. It's tempting to reduce your acquisition funnel down to the level of "here's how many people we dumped in the top, and here is the % rate at which they activated." The truth is a lot more complicated. Too many people overlook this and optimize for what is working, which puts you at risk of unknowingly niching down into a small portion of your addressable market.


Great point. Responding to feedback from the ‘wrong’ customers kills so many products/startups.

This is the point of methodologies and techniques like Customer Development, Ideal Customer Profiles, and good ol’ fashioned business modeling.


>Responding to feedback from the ‘wrong’ customers kills so many products/startups.

That's something I wonder about with Show HN. Aren't many of us on HN inherently the 'wrong' customer for any product or service that aspires to be mainstream?

Famously, for example, 10 years back, some of the comments when @dhouston submitted "My YC app: Dropbox - Throw away your USB drive" [1] pretty strongly indicated 'wrong' customer.

I won't pull out the comments, because: 1. I don't want to make it personal & 2. It's with the benefit of hindsight.

[1] https://news.ycombinator.com/item?id=8863


Exactly, powerusers are in many ways actually terrible customers because

1) They are ok with using worse/harder solutions because they know how to use them.

2) They don't like to pay for things.

3) They are much more technically adept than the general population.

4) There aren't that many of them compared to the general population.

5) They skew towards 20-35 years old, white/asian men with good income.

For example, this startup: https://unlockd.com/ pays you (via phone bill discounts) to watch ads on your phone after you unlock it. It had raised $17m as of May. I first thought it was the dumbest idea ever, but then I realized that this was because I would never use it. In fact, I couldn't even see my friends using it. That doesn't mean others might not.


Power-users are not good proxy's for broad markets. But then aren't there markets where power users are the bulk of users and are actually willing to pay?


i agree with you here but sounds like you are mostly talking about "Early Adopters"?

Power users of a product who get deep recurring value from your product are get to analyze. they may be mostly earlier adopters at first but hopefully will grow to be your core customer.


thanks for the comment. agree that chasing after the "wrong" customers is a whole pitfall unto it's own. Nothing here says you need to chose your user based on existing top of funnel. Often times those are earlier adopters who try something and leave.

When thinking about your products critical user journey you need to think about ideal cases: who is the User, what is their Goal and in what Context they are using your product. Lots of work goes into understanding each of these to hone in on specifics for each product and definitely much more detail than this first article.


This article seems very similar to "Jobs to Be Done": https://hbr.org/2016/09/know-your-customers-jobs-to-be-done


Nice to see this here. I have spent a lot of time over the last year or so studying this. myself and the rest of our UX team did a three day JBTD seminar last year. Very valuable in shifting your perception of how to create stuff that adds value in people's lives. I highly recommend it for any person building software, as well as Outcomes-Driven Innovation which offers a great framework for making new things and figuring out empirically what users (or "the market", whatever) are asking for.


I'm curious to see what improvements to your workflow and to the experience you have seen. I'm open to anecdotes but I'd love some metrics if you have any.


I can't give specifics since I'm no longer with that company and even a cursory search of my profile here could put 2+2 together, but using an outcomes-driven framework survey (~150 respondents, we were a niche industry so this was a huge sample size) we were able to add critical new features to our roadmap that were opportunities we never saw before. By using the formula in that book you are able to objectively determine underserved portions of the market "I really need the ability to do X, and currently am very dissatisfied with my ability to do so with my existing setup". And by using numbers, which is cool.

More on the research methodology here: https://medium.com/envato/a-step-by-step-guide-to-using-outc.... I realize this seems a bit OT from the original comment, but Jobs to be Done and ODI are the same authors and they are intimately tied together philosophically


There is a video of Clayton Christensen on BoS that's really worth watching.


This one? http://businessofsoftware.org/2012/02/professor-clayton-chri...

I can also recommend the HBR article mentioned above.


That one, yes! Thanks for the link... I forgot that little bit.


To me, it's sad that this isn't just called "software design". If you aren't building software to solve your users' problems, why are you building anything at all?


Because often a software application is many things, with alot of features and power.

The people who design and build it understand the entire picture and can see the value (hopefully).

It can be very hard from the position of totally understanding a system, to put yourself in the shoes of someone encountering it for the first time, and it can be hard to see what they see when they first use it, and it can be hard to empathise with their journey through learning the software application that you have built.

This is an incredibly valuable article because it helps people who have built systems to put themselves in the shoes of their users - that is not an intuitive skill.


Another problem that we faced at my little startup is the public perception of our product is different that what the product really can do.

As an example, we are somewhat known as an “online therapy” company, while we do offer that capability, that’s just a tiny part of the value we provide customers (behavioral health private practice professionals.)

And as a previous commenter said, you have to be careful listening to feedback that might inadvertently “over-niche” your product thus losing out on a larger market. As a result we’ve been careful to onboard users in such a way that “online therapy” isn’t the headliner feature being presented while still being responsive to those that find us because of online therapy-related organic traffic.

Marketing and “framing the solution in a meaningful way” is the toughest challenge there is. For us, the tech is the easy part, it’s the damned psychology of the users that keep me up at night – which is funny to me because our customers are psychologists/therapists/behavioral health pros.


We face the same problem in an even more niche market. It seems to be very hard for customers to understand that a product can have more than one use and that the first use they think of is not the only use.

We haven't solved this problem, but our current thinking is focused towards splitting up the application into separate offerings solving one thing at a time - ultimately a worse solution for the customer, but one with a lower cognitive load.


thanks andrew. glad that you thought it was valuable.

you summed it up quite well. it is very easy to lose sight of what your users go through for the first time every day when you are the one adding to the system to extend or expand it.


Usually this sort of work falls under U/X or "product design"- software design often means architecture.

I get the sentiment, but specialization exists for a reason, and this sort of thinking could work just as well for a retail experience as it can for a software product.


Agreed on specialization being valuable, but the issue that arises is when this type of UX/Product process isn’t in place the specialists tend to spin out of control and lose sight of the users. And likewise, the UX team really, really needs those architects on their team to both help ship the experiments/improvements and make sure they aren’t proposing features that aren’t technically feasible with a given budget/timeline/tech stack.

Some of the best ‘UX’ solutions I’ve ever heard in meetings came from the software architect, usually along the lines of “Ohhhh, THAT is what the customer is trying to do? We can repurpose the flux modules pretty easily and ship that in a week or two!”.

Without good software architects on the UX team, designers will often punt on some of their more creative ideas because they assume it won’t be possible. A great architect tends to battle boredom, so the push/pull with designers can often keep them engaged and challenged. Win-win!


So much this! Too often UX and SWE are black boxes to each other and thus there is a loss of, pardon the buzzword, “synergy” that could be driving progress towards making customers love your product.


completely agree. most "Critical User Journey" articles are written by UX or product designers.

this article was meant to be an introduction to show how any product, startup, or company can use User Journeys as a framework for product development (not just product design) and how if executed in a systematic way can unblock growth.


Glad to see you in the comments Austin. Would love to hear your thoughts on cranking up growth on a project of ours!


sure. happy to chat. ping me at austin [@] initialized [.] com


It is just rebranded UX Design, and a pretty oversimplified version of it.

A few years ago, Google leadership initiated a "Product Excellence" initiative, the cornerstone of which was identifying and measuring CUJs, with the specific goal of improving UI/UX execution. This was because the UX of a lot of Google products was, well, not great. Implementation quality was low, in many cases because engineers were building what they wanted and not what was specified or designed. After all, it's an engineering company and this is ingrained in the culture. CUJs were a tool to rally people around building the right things at a high (enough) quality.

I'm not sure why they created new terminology. Either way, it was mostly effective. I wouldn't call most Google UIs "excellent" but they are at least passing usability benchmarks now.

An added side effect is that this methodology, like design sprints, created a new thing for evangelists to evangelize at Google and beyond. Hence the article.

Source: Grouchy Googler.


If you use the mantra that you are the user, and you build something for yourself with a small following, then you might miss a much larger market if you don't look for or seek out these hidden "journeys."


Sure, but the management of software design needs some serious work. We know how to manage the actual engineering process, but the design work still feels like black magic half of the time.


I feel the same way, but the other way around: design is MUCH more predictable than the engineering side in my experience.


As we’ve been discussing the user/customer life cycle quite a bit now, to take a closer look and know more about a specific customer/company, we need a tool that does more than just showing where users clicked, focused and similar.

Zarget’s Session Replay is one such feature that captures and plays the user path without any flaw in the user usage patterns. Importantly, having the hold of real-time user interaction data will help us conceive when and why the losses are happening. And with such strong insights it gets easier to fix any conversion funnel (regardless the type business you’re in).

Perhaps, employing a session replay tool to map out the critical customer journeys is the only possible step we could take to fix this issue.

Whether we dogfooded? Yes, we ran recordings within our product. It busted many myths on users’ behavior and needs, as we were able to track our own journey as a customer. And we were able to make changes to customer’s onboarding process and do tweaks based on the findings. Now our product managers know how users interact inside our app and don’t make any guesswork on how users will adopt a feature. Also, our product folks can’t live without Session Replay anymore.

https://zarget.com/features/session-replay.html


Can this session replay deal with secured fields like credit cards? e.g. during the replay don't record the credit card field

I'm just wondering how any technology like this would work in a PCI compliant environment.


We take security and privacy seriously. We don't track any sensitive data including Credit card numbers, CVV, passwords etc., Zarget cleverly tracks these fields and masks those details while it is recorded in a session. Hence, the user can be assured that their payment details are secured and safe.

https://docs.zarget.com/v1.0/docs/handling-sensitive-data


what type of overhead does this add to a mobile site?


Yes, Zarget works great with mobile site. It lets you see users scroll, tap, mouse move etc., on the mobile devices - both phones and tablets.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: