As apps become habits, they can become addictions for many who have a hard time limiting their use.

The two titans in the mobile space, Apple and Google, have both realized this difficulty and have released features for users to better understand and control their mobile use. Apple’s solution, Screen Time, and Google’s solution, Digital Well-being, both visualize the apps that are used most and allow users to set daily time limits to curb usage.

 

Although it’s commendable that both companies focused efforts on the problem, we believe that it’s not nearly enough. More importantly, they don’t consider the science behind habit forming products.

It’s hard to end habits through self control

Both features allow users to set a daily time limit for a desired app. When the user reaches their limit for the day, a screen is overlaid on their app reminding them to curb their usage.

Reminding a user they should do less of something isn’t enough. Over time, users become immune to the warnings and dismissing it becomes muscle memory.

Its easier to end a habit by replacing it with another

As principles of habit forming teach us, one of the best ways to end a habit is to replace it with another habit altogether. Don’t just warn, give the user something else to do. That’s why we built Unhook.

 

Introducing Unhook

Our small team came together to build Unhook – an app for Android that visualizes app usage, sets time limits, and asks user to take a 2 minute walk if they’ve reached their limits. By replacing the habitual nature of spending time on our mobile phones with that of light physical activity, we’re replacing a bad habit with a good one.

We’re just getting started and are in a closed beta gathering feedback.

Visit our website, http://www.unhook.app, to learn more and to sign up as an early tester.

Naomi Ionita, Partner Menlo Ventures (previously at Evernote and Invoice2go), gave a fantastic presentation around setting up a successful product org. I highly recommend watching it as it’s full of great insights.

One slide that really resonated with me was the idea about how metrics trickle down from company goals all the way down to an individual’s work.

The best product organizations have strong alignment. Everyone knows why they’re building what they are and how it could potentially impact the overall company.

The PM is the messenger

I believe that he PM plays a critical role in ensuring that team members understand the overall company goals and how they trickle down to their own individual work. PMs act as the glue that brings goals together and they should often repeat and remind their team members.

Some ways to do so include:

• Repeat Often, Include Often
  Structure your team presentations and potentially even product specifications around high level product goals and work your way down to the feature. Sometimes this can be a few words and sometimes a diagram does the best job.
• Remind During Metrics Review
  When looking over usage metrics of a particular feature, begin by showing overall metrics that relate to company goals. Even if that goal is financial and the feature work is around usage, simply mentioning and reminding team members of the overall direction is helpful to set the tone.
• Get Others Using the Same Shared Language
  Ensure team members know the overall company goals and team goals by asking them to mention them during their presentations and their reviews. This could include sprint planning or even design reviews.

PMs need to be the leaders here. Engineers, designers, and fellow peers can be far more motivated to do their best work when the company goals translate into what they’re doing each day so they know how it fits into the bigger picture.

Experienced PMs will tell you that most of the product ideas they’ve worked on haven’t actually come from them. A good PM sources ideas from different avenues and focus on ones that have the most potential to solve user pain.

Employees-Metrics-Users-Clients (EMUC)

I’ve found that the Employees-Metrics-Users-Clients (EMUC) framework, taken from an article written by Rishiraj K, provides a straight forward way to think about sourcing ideas.

Employees

In a good product org, employees usually talk to the users at all levels based on their area of engagement such as operations, business development, customer support or sales. Sourcing ideas cross functionally from employees can really help find diverse suggestions.

Metrics

Sourcing ideas from observing the data and metrics for the product can really help focus on key areas that need improvement. Example: you may observe a significant drop within the user on-boarding flow and, therefore, it would inspire new ideas, such as re-thinking the content or the flow itself, to improve conversion.

Users

Good PMs are always talking to users. Monitoring key feedback loops for your product, such app reviews, support tickets, usability studies, customer success meetings, and others can help source ideas at the root of the problem.

Clients

Often applicable for B2B products, where the customer/buyer may not always be the user of the app, can help source ideas that extend or add certain functionalities to the product for particular use cases.

Do we really need another acronym?

Most acronyms are redundant – so why is EMUC meaningful?

The EMUC acts like a checklist to ensure you’re considering each source for ideas. Even though obvious, it’s easy to not consider all of them when building.

It’s important to note that EMUC provides the input sources; the who. How one does the actual idea generation (ex. Design Sprints, Brainstorming, etc.) is something I’ll cover in the future.

What makes a good Product Manager into a great Product Manager?

Talking to customers, understanding the industry, working with engineers and designers – these are all standard things that all PMs need to do to succeed. However, to do them exceptionally, it almost always comes down to communication.

A core part of communication that many PMs don’t focus on enough? Writing.

“Clear written communication is an absolute prerequisite for a product manager” — John Cutler

And I’m no exception. I haven’t given writing enough practice and I want to change that. This blog is for exercising that muscle.

Writing helps you learn

Ravi Kumar wrote a great summary around “Why must all Product Managers write” that covers the topic well.

He interviewed a few PMs and there was a quote that really spoke to me:

“Writing is absolutely a learning process for me. I write about anything that I want to learn about because when I try to write about it, it forces me to learn.

It doesnt matter what you write is not very good. You dont write to impress anyone else. You write for yourself. Writing, sharing, giving talks is first and foremost is for yourself. They are all rich learning experiences for your own self.

Even if no one reads what you are writing, it still is worth the effort because you will learn and become better.”

— Yevgeniy Brikman, Author, Hello Startup

The idea that writing actually helps you learn is something most PMs don’t think about and it motivated me to get this blog started.

314 words or less

However, like any good PM, it all comes down to scope. To make writing this blog achievable and to practice brevity, I will limit each post to no more than 314 words.

So here goes! My thoughts on building great products in 314 words or less.