How To Not Be Pushy With The .gitignore in Git


Image by Ramotion studio

There are things one never wants to store away into a version control system such as Git. In the source code world, we’re talking about junk like temporary editor files, .DS_Store, and user specific files. In a team environment, it’s essential to not burden others with things that only you care about.

So one typically creates a .gitignore file. Usually that takes care of everything you need. However, there is that awkward moment where you want to add something to the .gitignore file, but it only pertains to you. Worse, what if it only pertains to you in a specific project?

There’s a great article titled Ignoring files which outlines just what you need. As it says in the article, you can use the “explicit repository excludes” approach. You just have to change the .git/info/exclude in your Git repository root. For example, when I do a git status, it shows:

Untracked files:
(use “git add <file>…” to include in what will be committed)

If you change the .git/info/exclude in your Git repository root, it takes care of it.

This is a great solution if you are not worried about losing some simple .gitignore rules and they are project specific. In my case, I simply added the following to the mostly empty exclude file that is already there:

Done! It’s that easy.

Given that I work at a place (CARFAX) which prides itself on knowledge sharing and software developer growth, I decided to blog this here for all to enjoy. So, enjoy!

Communities in Nonsocial Mobile Apps

Nonsocial apps with a social community inside of them. It seems to make sense since you already have a captive audience. However, does it always make sense? Let’s first dive into mobile apps that come with communities.

Besides the obvious social mobile apps, there are multiple apps with communities aka groups inside of them. These apps are not primarily social apps, but they attempt to support a community. Since humans are social beings, it can be a nice feature which can make the app more appealing and thus used more often.

Some Community Supporting Apps:

  • Argus – It’s a highly social activity tracker app that has a groups section. There’s more on Argus further down in this article. iPhone and Android apps exist.
  • Coursera has a “Discussions” area in the iPhone app. There’s an Android app too. Discussions are not available until a course starts. So, one cannot peek inside right away and explore it.
  • Lose It! – Weight Loss Program and Calorie Counter – Has a “Social” section with many groups in it. The group activity in it is kind of strong. Strongest are the groups which are promoted as “Featured Groups”. iPhone app and Android app exist.
  • Not quite a discussions area, but Udemy has a Q & A section which has questions directed at the instructor in a particular instructor. This provides longterm value with credibility in the information since the answers come from the instructor. However, there is no sense of community. They offer an iPhone app and an Android app.
  • It’s worth noting that I have seen apps drop support for groups. That can sometimes be the smartest move.

More on Argus

The target audience of the app focuses on people who like to be social while tracking health, fitness, meditation, sleep and other trackable activities. Even though the semi-new groups section is pretty dead, there’s a novel tie in from a group into the tracked activities of group members which I find interesting.

It’s interesting in how it provides a kind of newsfeed style of tracked activities. You can tap on a button in the group and see a combined newsfeed from the group members. Compared to the messages button, this has much more activity. Unfortunately, most of the activities have nothing to do with the particular group you are in since they are not filtered. At a glance, it’s also a slightly confusing user experience.

Also, the downside of the groups section is that it’s slow to load and has an annoying bug which makes the iPhone app crash when you click on a link. As a side note, I happen to run a meditation group in Argus that has 25 members.

All that said, it’s worth a look. The groups has potential if a few things are tweaked, promoted, and fixed.

Externally Support the Community?

Should one just tie into an existing social app such as Facebook to support a community? It’s a fair question. Facebook has a groups feature which can be successful. The most successful Facebook group I have been a part of is the Octalysis Explorers. It has over 2000 members. Like any group, a lot of effort goes into keeping the community engaged. Fortunately for the Octalysis Explorers, Yu-kai Chou is a master at the art and science of engagement. He has a handful of awesome and loyal people who support the effort.

The people supporting the Octalysis Explorers group are continuously driving people to the Facebook group through multiple channels. Even in its own “Join the Movement” section, the group is highlighted in Yu-kai Chou’s great book titled Actionable Gamification – Beyond Points, Badges, and Leaderboards. There are also multiple administrators for the group. Also, there is always at least one person actively interacting with every post. A successful community relies on that kind of wonderful support from its administrators and its members.


Even though the implementation and user experience is pretty rough, it seems like the app with the most group activity without overt support is “Lose It!” However, that’s not saying much. The app with the most potential from a technology point of view may be Argus. However, Argus is already a highly social app so its group feature doesn’t add much.

If one can dedicate people to supporting a community on Facebook, that might be your best bet. If you go that route, you will need to continuously drive people to the group through your existing email marketing, verbal announcements in events or podcasts, and every other chance you get. Communities require care and feeding.

No matter how you support a community experience, it can provide an advantage over other solutions who don’t provide such. If one cannot dedicate the resources to the community experience or if the community experience doesn’t ever pay off, my advice is to drop it and refocus on other things.

I want now!

Freeing Yourself From “Want Pain” Through Meditation and Octalysis

I want now!

Pain by Nathan Phillips

“If I don’t get this, I’m going to just die.” Ever heard something or said something like that? Did you ever want something so bad it hurts?

How does one free themselves from an undesired want? How does one still respect the aspirations which guide us in life?

As Joseph Goldstein had said in the 10% Happier app in “Non-Attachment to Results”, aspiration is a good thing. There’s nothing wrong with it. Expecting and becoming attached to the results of going for something is when things turn sour. There is a difference between wanting something with a unhealthy attachment to the results and energetically striving for something. It’s ok to go for something. It’s undesirable to get so caught up in the outcome that you set yourself up to suffer.

Now if you are not yet fortunate enough to be enjoying the 10% Happier app subscription, there is something else you can listen to called Joseph Goldstein: Letting Go of Expectations & Craving.

However, I recommend getting the 10% Happier iPhone app or getting on the web and listening to:

  • “Will Meditation Kill My Edge?”
  • “Non-Attachment to Results”

Yes, to get to those two items, you have to subscribe. If you’re not ready yet, get the app and listen to the free Q & A and courses first. I share more about the app in a slightly older post titled 10% Happier Meditation App Is 100% Satisfying.


Releasing yourself from painful wants can also tie into equanimity. This insight came upon me while listening to the “10% Nicer” section of the 10% Happier app. If you are not subscribed to 10% Happier, you have to spend more time digging around more. Since I really dig people like you exploring meditation, I dug into the internet for you.

There’s a funny and enjoyable video titled Sharon Salzberg on EQUANIMITY for InsightLA (Part 1). It’s a great video. Yet, it takes time to digest.



Is there a totally different way to view this? Absolutely! Let’s view this from a human behavioral design approach using Octalysis from Yu-kai Chou.

In Octalysis terms, it’s best to focus on what you want in life from a Core Drive 2 (CD2), Accomplishment and Development approach as opposed to Core Drive 8 (CD8), Loss and Avoidance. With CD2, you try something. If it doesn’t work out, you change the approach and try something else or you decide to try for something different and perhaps better. CD2 is white-hat and one is energized by pursuing it. CD8 is black-hat and the most you can hope for is the avoidance of pain. The avoidance of suffering. There’s a lot more to Yu-kai and Octalysis and even an Octalysis Explorers Facebook community if you want to explore Octalysis and its application to your life further.

Now What?

So, “now what” you ask? Although you effect every single person you interact with, how you approach life is your choice. What I have found useful is to remind myself why I am striving for something. What is the good and higher purpose of what I intend to achieve? I win the game of life by trying, being resilient, letting go of attachments to outcomes, and changing direction as needed. I also keep listening to the 10% Happier app and exploring Octalysis (TEDx talk). May you be happy, healthy, and at peace as you energetically strive to achieve great things in life.



iOS Color War! Appearance Proxy vs UIButton Title Text Color

Now here’s a weird issue that appeared in iOS 10, I found myself saying one day. I was seeing an iOS button’s title change color as a I navigated from one scene to the next. It got worse. When I navigated back, the button’s title color stayed the wrong color. It was the same color as all the labels in the iOS app. What’s going on?

We dug in deeper and discovered something. There was a nasty appearance proxy color issue where the appearance proxy would change the color of the UIButton‘s title text color even though the code was explicitly setting the color. In fact, the appearance proxy would set it to be the same color as it has configured for all UILabel objects. The configuration code for labels was like this:

UILabel.appearance().textColor = labelTextColor()

Since a UIButton contains a UILabel, that might make sense. How does one fix this situation?

The answer to fixing it was discovered after thinking about what was read in this Stack Overflow post titled Appearance Proxy overridden when resetting text:

iOS applies appearance changes when a view enters a window, it doesn’t change the appearance of a view that’s already in a window.

It turns out the code to explicitly set the color on the UIButton was getting called before the view appeared on the screen aka viewWillAppear. Once the view appeared on the screen, the appearance proxy would set the button’s label’s text color aka button title color.

As a side note, this only seemed to happen when using setAttributedTitle on the button as opposed to calling setTitleColor and setTitle separately. Unfortunately, we wanted different parts of the text to be different sizes. So, using setAttributedTitle still seemed like the thing we should do.

Given all that knowledge, we called setNeedsLayout on the UIButton in viewWillAppear and viewWillDisappear That fixed everything up! The button no longer appeared to change color when switching between screens. Hurrah!



Notes on “Demand Validation is Product Management”

The focus of the Demand Validation is Product Management episode is about answering the second question of these two standard questions:

  • Is this product useable?
  • Do people want to use it? – This is Demand Validation

The guest is Steve Cohn, Founder of Validately.

The rest of this blog post contains pretty much raw notes. The notes contain a mixture of direct quotes from the podcast, my own thoughts, and sometimes ideas that came to mind while listening.


Steve Cohn got a lot of false positives. It begs the question: “How is great innovation brought to market?” It’s relatively easy to define and validate the problem space.

There is a gap between “Is the problem worth it?” and “Solution you have in mind.” Do people want to pay for or talk about your solution?

In comes Demand Validation. Validate the solution space. Figure out ways to run rapid prototypes.

Back to the false positives mentioned above: 50% of the features go unused by customers. “They passed the internal sniff test.” 30% of the work that a product team does is rework. Product teams ask customers “would you use this?” which is a bad indicator of demand.

People are not misleading you on purpose. There’s a gap between the hypothetical desire and committing to the solution. The “cost question” is better. Until you make saying yes cost something, their answer is meaningless. It forces the consumer to make the mental tradeoffs. For the “free products”, instead of costing money we go with time and reputation. So, the three things of possible interest are:

  • time – Is the problem deep enough to give their time for free to help you “create” the product?
  • money – Money comes in prepaying or signing a contract.
  • reputation – Social sharing is the reputation.

If people care about the problem and are compelled by the solution, they will work with you to create your solution.

Money comes in prepaying or signing a contract. Kickstarter is an example for consumers. For businesses, you can pre-sell all the time.

If you get a “no it’s not worth their time / money / reputation”, ask “why.” Knowing why is important. Customers are good at telling you what is not compelling about what is in front of them.

Backlog Prioritization 

Product Management is harder at bigger companies. Some examples include marketing, finance and executive. Marketing is saying there is a feature buzzing out there in the marketplace and we need to do this. Sales say a big customer needs this. Finance says where is the ROI for this feature? Shouldn’t you build another one? Executive says they had a great idea in the shower.

There is a saying mentioned: If we have data, let’s go with data. If we have opinions, go with mine.

Solution: Do Demand Validation Tests at the prototype stage with your backlog. We’re talking about rapid experimentation and getting the data. Then you can respond with the data. Yes, we prototyped it. We tested the idea against the customers and this is what they said. It went poorly so why should we build it? If it tested well, build it ASAP.

A feature prioritization process built on opinions will fail. You need to prioritize based on data.


The true concept of the MVP is brilliant. The problem is when there is a misunderstanding about MVP. He likes to use the term MVE, Minimal Viable Experiment. We’re learning through this experiment. It’s understood that an experiment yields learning. When people hear product, they think growth. So, instead of MVP let’s call it MVE.

We’re in the home-run business. We have to consistently hit home-runs. There’s only one way to do that. The home-runs strike out a lot. So, get lots of trips to the plate. Take lots of swings. Run experiments. You will get a lot of strikeouts. However, you have to do that to get the home-runs. Give the team flexibility to try crazy things.

When Do Product Managers Know They’ve Hit It Big?

Alpha-UX are thought leaders on this. Spit-testing prototypes. They use high volume. They shoot for statistical significance.

The thing you want to understand about validation is that it’s not a guarantee. Lean is about reducing waste. Removing things that definitely won’t work. Prioritize those things that have the higher probability of achieving market success.


  • Do Demand Validation Testing
  • Experiment often
  • Use data to help prioritize the backlog
  • Use the term MVE instead of MVP to set expectations

Notes on “User Research Is Product Management”

The focus of the User Research Is Product Management episode is about going beyond simply User Experience. The guest is Jack Cole, a director of design. User Research is critical to product management decision making. It’s beyond just trying to make “cool stuff.”

The rest of this blog post contains pretty much raw notes. The notes contain a mixture of direct quotes from the podcast, my own thoughts, and sometimes ideas that came to mind while listening.


User research is a through line throughout any type of product lifecycle. — Jack Cole

We focus on users of a certain age or economic background. We do interviews with people, uncover their goals and understand where they are trying to get some additional value. We’re trying to understand the “opportunity space” that is there. We want to create “habit forming” products.

We break it down around the key factors / features that “certain user groups would be be looking for.” We want to go for trends. We uncover them. Next, we go for those identified age ranges, economic backgrounds or areas of the world.

Formal interviews are not the only way. His company has built out friendship groups. It’s more of a casual atmphosphere. They build on a conversation and a level of trust to identify where the opportunities are.

Discover existing pain points and trends. This is done before proposing new ideas and value propositions. Hoping and Praying that things are on target is not fun.

How to Find the Right Users? Who To Talk To?

Envelope yourself in the project. Start gorilla style. Ask around.

Metrics and Data Points

It’s about trying to identify themes in the discussions. Map them out. You can see opportunities based on what is common in the responses. See an opportunity? Build on a hypothesis and on those elements. Objectively identify themes and narratives in data. It’s about quantitive and qualitative information. Shake out the truth vs what is an anomaly. Build out ideas and test.

Common Problem

Trusting in the first interview you hear is a problem. See the themes and through lines. Don’t trust just one voice.

B2Bs count too. Even if the customer base is established, we can achieve better adoption through a deeper understanding of the end user. Come at this through a path of humility. You don’t know everything. There’s always something new that can be pulled out. New innovations can spring forth.

Risks of Not Doing User Research?

  • Loss of time, money, and resources.
  • If the culture doesn’t embrace it then you get Product Manager burnout.

Evangelizing Tips

It doesn’t have to be time consuming or extensive. Engaging your user community is a form of research.



He also suggests checking out the blog posts at


  • Do user research by doing interviews.
  • Map out themes from the research.
  • Evangelize through community

There’s certainly overlap in this episode with other episodes made by This is Product Management. However, this episode is highly focused which is refreshing. As listed above, the podcasts shared and things he is reading are certainly worth looking into. From what I have seen where I work at CARFAX, understanding the users through user research is a must have. CARFAX gets it. An understood user is a user who will rave about your company.

Notes on “User Experience Is Product Management”

The focus of the User Experience Is Product Management episode is on User Experience and things that impact such work. The guest is Sarah Doody, a user experience designer.

The rest of this blog post contains pretty much raw notes. The notes contain a mixture of direct quotes from the podcast, my own thoughts, and sometimes ideas that came to mind while listening.


Sarah works 50% on startups and 50% on companies that are in the market already. She helps them figure out where they should optimize the user experience. She does teaching and writing on the side. She even will be launching some curriculum in 2016 hopefully.

Her Background

She has always been interested in the tech scene. When growing up, she was interested in neuroscience. Specifically, biofeedback. However, that requires medical school. She realized she couldn’t make it through medical school. It’s too gory.

She went to Texas and attended a community college. She did internships. She did web design which was good because her left and right sides of the brain were both used. She took business courses. She took Graphic Design. She did some front end work.

Eventually, she got a full time position in Oregon on a web team doing maintenance of sales sites. She didn’t have a degree yet. At some point, she was asked to do banner ads. It was then she realized this career path was not going to suite her well down the road. He dived into learning about user experience.

She did a startup for five years. After that, she “started her own thing” in 2012.

Intersection of UX and Product Management

User experience involves all the touch points with a product or service. Although there’s the online experience, there could be offline too. There was an example of a frame company. They had a photo of the frame. The product was packaged in beautiful paper. There was a hand written note. It was a great experience. The experience doesn’t end when one leaves the website.

Role Confusion

There’s a difference between UX and UI. UI deals with what does the site look like? It deals with icon colors. UX is stuff before that. How did they get there? What tasks do they want to do? The whole customer journey.

Data Informs How?

Don’t sketch until you’ve talked with people. You don’t have to have a complicated setup with a user lab. You can do research without too much time or budget.

Here’s an example. For one project, she started with doing twitter, message boards, and Quora searches. She tried to answer:

  • What are people doing to solve the problem now?
  • What websites are they using?
  • She spoke with x people in Twitter and x people in Quora.

For her current project, she just got done with a two week research trip to Atlanta, GA. They interviewed people personally in their own environments. They will now take hours of interviews and comb through them and find common themes (Personal thought: Is there an AI opportunity here of finding themes?). They spot themes that come up in each interview. Just spot patterns and understand people’s behaviors at the macro level.

Mistakes Teams Make

Classic mistakes deal with testing on their site. They test too many things at once. Control your variables. Choose one or two things. Otherwise, “the data you get is garbage”.

A tool she likes is Optomizely. It’s simple and you don’t know have to know how to code. She used it on her blog for example. She would test and tweak the location of a social image or button.

Another tool is Crazy Egg. Can see people’s scroll or mouse patterns. It’s good to use a variety of tools. She might use both. That way you get diversified data.

There’s a misconception that you need a massive sample size for interviews. (Like one that needs 100s of people.) She just spoke with 16 people. After the 4th person, they are seeing patterns. The patterns are the same patterns over and over. By the 15th person, you are feeling real done.

If you are doing A / B testing, you need a minimum of a couple of 100 people. It all depends.


Micro-UX? It’s a small touchpoint that adds a delight factor. Delight in the sense of the experience just works. There’s less thinking required by the user.

An example is the user types “c..a..m.. and predictive text fills in the rest. It helps you get to what you want fast. Another example is with a password form field where there is a show link. You click the show link and you can see the password you just typed in.

Grab the Feedback in a Timely Fashion

It’s important to rapidly grab the feedback from the user after they just did an important task.

For example: She rode in an Uber. A little survey popped up which would let me rate them. That’s micro-feedback. She completed an important task with a product. So, get the feedback close to the point of transaction so you have a chance of getting any feedback at all and it will be better data.

Here’s an example of doing it wrong: Delta. They asked for feedback 3+ days later. They sent an email. They asked “How was the flight?” Click here for a survey. It was 15 to 20 questions long. It’s too long. It looks bad on mobile. They should just send a text message. It should be something like: I saw you landed on Boston. How was your flight: 1 – 5. Done.

Story Telling

She wrote in 2011 Why We Need Storytellers at the heart of product development. Based on a rant on her blog.

She noticed teams that she worked with that the team itself would be over budget, over timeline, bloated with features or sometimes too little features, and the users would not adopt the features. Why is this happening over and over?

It’s like this. There’s a beautiful vision in mind and then what comes out is nothing like what you had in mind in the first place. On Pinterest, you see cakes and decorations and then you try to mimic what you see.

The reason is because we don’t spend enough time in storytelling. It’s because we feel progress writing stuff. However, it’s not real progress.

Spend more time working on the story up front. People will start to embrace it.

Idea: How to apply storytelling? Use storyboarding in the Product Management process. Imagine you are crafting a film. Scene by scene. They are in this particular environment. What are they doing and what’s their problem? Another scene, they have this problem. You have the solution. It helps you think about all the other factors. Example: A location based mapping thing. People are using it outside. It might be sunny. It could impact the colors. So, it might need less words. Consider the whole experience and the whole environment and not just the individual screens.


She wrote an article called 6 mistakes companies make when working with a UX agency or consultant

Be specific with the feedback. Example of bad feedback: I don’t like orange and green because I don’t like peas and carrots.

Be as specific as possible with the requirements as possible. (Personal thought: What about Agile and incremental / iterative development?)

Be actionable. How to draw out the requirements very very soon is important. Do more of the complex screens up front. It’s going to trigger 1000 questions for them and the teammates.

Don’t just say what you don’t like, say why you don’t like it. I don’t like this because (insert some real business reason).

Don’t hold feedback back. 1/2 way through is too late. Don’t say at the end, I haven’t liked everything up to this point. That doesn’t work. Don’t delay the feedback because that will increase cost.

The cost of change. Changes in UX; factor of 1. Changes in design; factor of 5. Changes in coding; factor in much more.

Don’t race towards the launch date. People see the holidays. A commerce site example: We need to launch this big thing by November. Running toward the launch date causes two things to happen:

  1. They end up launching a product with all the features, but all features are 70% quality.
  2. You start having to do feature slashing. However, you slashed so many features it’s worthless.

Don’t isolate your developers. Let the developers be involved as much as possible. They are close to the data. They have a good eye for UX sometimes. Look to them for ideas. Have them involved early on and they can help you figure out your time line. Example: Custom chat messaging vs using something out of the box.

Benchmark Question: How does she eat her own dog food?

Amusement park project example will explain it best. She doesn’t have kids. So, she reached out to a few friends. She asked: Ever lost a kid at the grocery store? She used her personal network. She Googled. She looked for products that existed. She spent an afternoon doing the research. She made a storyboard.

In her storyboard, her first screen box was them at a park. Second screen they discover the kid is missing. Next screen they want to take action. What’s the first thing you would want to do? First thing you want to do is report the kid is missing. Keep in mind they need to conserve battery because they are at a park. There was a total of 16 scenes.

That enabled a user flow document. She sketched out what screens would be needed. Similar to sitemap diagrams. Now it’s user flows or screen flows. From there, that allowed her to do wireframes for each screen.

She would bounce between the following as needed: storyboarding, storytelling, user flow / screen flow, wire framing. The main point is that you don’t want to start with wire framing first.

Benchmark Question: How does she get out of the office?

She did formal user analysis. It was too formal. So they developed a process to get information in a less formal and fruitful way.

They created a screener to identify the exact people to talk to. A recruiting firm was hired to find all those people. The quality of recruits is 100% dependent on the screener. Hours were spent on the screener. More time into the screener the better quality of recruits. A discussion guide was created. This consisted of a list of rapid fire questions. The goal was to make interviews conversational and informal yet the questions are in the back pocket.

She talked with people in their own environment. You get more information from people if it is their home or office. For activities on the computer, that helps. They are with the computer they are familiar with. They are familiar with the environment and devices. So she did research in people’s homes and offices.

Benchmark Question: Reading?

She has two books on the go always. For pleasure, My Paris Dream.

Second book: It’s more business oriented. The Shallows by Nicholas Carr. She’s not finished. It’s kind of around the idea that our brains are changing and are not static. What is the influence of the internet on our brains? Multi-tasking is bad. She has learned and confirmed content from there. The internet might not be good for our brains. It’s harder to absorb long form content. Reflecting and focusing on things is a challenge. We’re in distraction mode. We’re bombarded with content. The content may be swishing by our brains. It’s a hard read. However, it ties into her love of studying the brain.

Benchmark Question: Recurring Nightmare

Having projects and clients that lack requirements. There’s a lot of first time founders. People come into product management as UX or from another field. There’s junior product management that is good at the day-to-day. However, there is a product strategy gap. UX is filling that gap. It’s important to identify the requirements and create product roadmaps. As consultant, you want to have those things up front. She may want to figure out how to put the creation of requirements and product roadmaps into her contract.


The identification of requirements through a process of storytelling is consistent with great advice I have heard from other sources. It sounds like User Experience roles are still being confused with User Interface roles. Finally, the knowledge of how to get valuable insights and feedback from the user are invaluable. Having looked through her website, there are many other gold nuggets to be found at the Sarah Doody website. Also, don’t forget to listen to the User Experience Is Product Management episode made by This is Product Management.


Notes on “User Science is Product Management”

The focus of the User Science is Product Management episode is on User Science. It covers what User Science means, the tools involved and advice around implementing it. The guest is Brent Tworetzky, the Executive Vice President of Product at XO Group. Brent is on Twitter and Medium.

User Science is the study of users. It’s the combination of user research and user analytics. This directly aligns itself with interests that I have. Throughout my career and personal time, I have continuously sought to get closer to the end users of technological solutions. Through the power of enjoyable yet easy to use technology, I like to empower and enrich the lives of others. So, the topic of User Science is an area of deep fascination.

The rest of this blog post contains pretty much raw notes. The notes contain a mixture of direct quotes from the podcast, my own thoughts, and sometimes ideas that came to mind while listening.


Brent started as an engineer. He didn’t like the day-to-day of programming. So, he got involved in strategy oriented careers such as management consulting. However, he felt “removed from the action.” Product Management lets him put all the things he loves together into one role. As a side note, Brent goes into detail about the Product Management role in his article What Does a Product Manager Do?

Brent has his roots in Product Management from working with others who used to work for eBay, Netflix, and Google. With philosophies that came from those places combined, he has been exposed to different approaches that cover being business case driven, user research oriented, and the use of quick iterations. This all has been foundational to how he applies User Science.

Applying User Science at his organization answers the question of whether to continue to iterate on a product or to go a completely different direction. User Science is a combination of understanding the users’ intent and their user behavior.

Intent vs Action (Behavioral)

The tools involved with Intent vs Action can be expressed in this 2 x 2 grid that Brent provides in his article titled A Product Manager’s Superpower: User Science.

Product User Science Grid

Product User Science Grid


The purpose of exploring a users intent is to understand what problems the users are trying to solve. Using the intent tools, one is trying to nail down the important problems to solve.

Action / User Behavioral

Once you have the problem to solve, it’s time to switch to the User Behavioral side of things. This is where you can do things like prototype and do usability testing. You can do A/B testing or bucket testing. You can also do aggregate analytics.

From these tools you learn things like:

  • Do we have something that still works for what the user wants to do?
  • Should we iterate on this or is there stuff to throw away?

Diary Study, A Special User Science Tool

The Diary Study uncovers actual user behavior over an extended period of time. To do the study, they collect a small group of users that agree to share their thoughts and challenges. For example, wedding planning. They check-in every week or every two weeks over a two to twelve month period. The diary captures the needs and challenges of the user each week.

Through this tool, they learn what tools the user uses, what problems they have, and maybe what ideas they might have. Through all of this, the Product Manager can discover whether or not the user has experienced the kind of problem that is being looked for. In other words, if the users are experiencing the same problem again and again, that’s an interesting thing to learn and maybe you’ve found a problem to solve.

Implementation Challenges of User Science

User Science is a field that needs to be learned. It doesn’t come naturally or by accident. When new Product Management team members join their team, they explain and walk through the related philosophies. They ask them to put the tools into their hands and practice right away on practice tests. These new members also get tutorials.

The new team member gets tutorials from the User Research or Product Analytics team. For A/B testing, they use Optimizely. For usability testing, they use UserTesting. They run practice tests and get feedback about those tests. This lets the new team member get familiar with the tools and gain muscle memory about those tools.

On top of all that, their company also brings in guest speakers. The speakers show the capabilities of new tools and how to use the new tools to make “magical” things happen.

Some User Science Tools Need Others to Support

Using some tools requires help from others. For example, diary tests is something that takes a lot of time. His company has a special team to implement those kinds of things.

The trick thing about the tools is that we can’t just tell people about the tools. User Science is a field that needs to be learned. There are four learning curves / stages to User Science.

Four Learning Curves for User Science

One needs to learn:

  1. The tools themselves. For example, surveys, one on ones, A/B tests and more.
  2. How to do quality tests; Rookie mistakes are common. It’s easy to accidentally bias a test.
  3. What test to apply where. Is this the right test for a specific situation?
  4. How to use tests in a valuable way. How to gain value from the tests you do. For example, some beginning Product Managers will always use an A/B test for a new idea. That’s their go-to. Brent encourages the Product Managers to use tests to be more “provocative”. Since it’s a test on a small subgroup, the gain is so much greater than the risk.

For Those Getting Started

The User Science Field is advancing quickly. So his advice consists of:

  • Hire fantastic people. Help make people great and create an environment to succeed.
  • Share a clear vision and mission so all are moving in the same direction.
  • Make it clear what success looks like. He recommends Daniel Pink’s book Drive. It covers autonomy, the opportunity for mastery and a rich sense of purpose. From this, one can create a great team environment.
  • Focus on outcomes. Make things that matter.
  • Communicate, communicate, communicate. There’s no such thing as over communicating especially when companies grow.


As you can see above, the User Science is Product Management podcast episode is filled with great insight on what makes up User Science, the related tools, and some practical tips on its implementation. I highly recommend you listen to the podcast episode as well as the other episodes at This is Product Management.



POWN? Communication Technique

Listing out Pros and Cons is a tried and true approach for deciding whether or not to go with an approach. However, sometimes it’s not enough. For example, a long list of cons that a group comes up with compared to a short pros list may make it seem like it’s something the group shouldn’t do. Yet, the items listed are trivial. In dealing with such situations where something more elaborate is needed, I have come up with the “POWN?” communication technique.

POWN? stands for Positives Observations Weights Negatives Question. The Positives are like the pros in the pros / cons. The Negatives are the cons. The Observations are what people perceive, but it’s not really a Positive or Negative about the item under consideration. The Weights and Question take more explaining.

Every item that is listed in a Positives or Negatives column is weighted according to an agreed upon scale. For example, it could just be high / medium / low. So, a little ‘H’, ‘M’, or ‘L’ can be next to the item. The Question signifies that any group member can request a question mark be placed next to a Positive or Negative item. This is useful so that the group can quickly list out all the Positives and Negatives without stopping to debate each item as it is listed. This brings us to the process of using this communciation tool.

The process of using the communication tool is up to you. However, one can apply it in the following way:

  1. Columns with labels are made on a white board. Positives, Negatives, Observations. Ensure enough room is between the columns for the Weights and Question marks.
  2. The group is asked for all the Positives and Negatives. They are listed. If someone challenges or wishes a deep understanding of a Positive or Negative, a question mark is placed next to the item and the group moves on. A quick question / answer is allowed. Speed is the name of the game at this point.
  3. All the items with Question marks are resolved by the group. Speed is not the point anymore. The point is understanding. If the group decides to keep an item listed under the Positive or Negative, a Weight is placed next to the item.
  4. Throughout this whole process, observations are listed under Observations. For example, “We gained a 20% increase in productivity when we applied our last experiment.”

There you have it. A slightly more elaborate pros / cons like technique that allows for deeper clarity into a situation. I hope it serves you well.

Notes on “Mentorship is Product Management”

The focus of the Mentorship is Product Management podcast episode is on how to form valuable mentorship relationships between a product manager and a mentor. The guest is Ben Foster, author of Most Product Managers Suck.

Throughout my life, I have sought out different ways of empowering people through knowledge sharing. Among other things, I founded a Technology Mentor Program at CARFAX  So, this podcast was of particular interest to me.

The rest of this blog post contains pretty much raw notes. The notes contain a mixture of direct quotes from the podcast, my own thoughts, and sometimes ideas that came to mind while listening.


Ben had a statistics degree. He got a job doing QA, filed bugs, and got some enhancement requests. The product managers at his company invited him to become a product manager. That was in 1998 in San Francisco.

He joined eBay in 2001. The company grew fast. Ben rose in the ranks of Product Management. (How did he do that?) At eBay, he was in charge of merchandising which is all about “Would you like fries with that?”

He later became VP of product management at CoPower, an energy efficiency company for about four years. They took the company public in 2014.

Now, Ben helps founders and product managers. Every product manager can benefit from having a mentor. Decision making is what a product manager does. They have backlogs.They have strategies. They have to decide how far out to communicate a roadmap. They need good judgement and wisdom. Mentors help with the wisdom part. Mentors have:

  • Prior experience
  • Functional know how
  • Domain expertise

What’s Better, a Formal or Informal Relationship?

There are many different types of relationships. Paid vs. not-paid. Where the mentor is extremely senior or a peer. It depends on the needs of the mentee and the needs of the mentor. What are they trying to get from the relationship?

For the mentee, are they looking to do a current job better or take that next step in the career? Do they want formal or informal? Do they want a really good peer or someone more senior? Do they want someone in the same organization or outside of the company?

If you get a mentor that is inside the same company, the mentor has the context and is already familiar with what’s going on. If the mentor is outside of the company, they can offer benchmarks on what you are doing well or not based on comparisons to other companies.

Common Use Cases for Mentees:

  • Some have laser focus. They want a promotion.
  • Others are brand new. How can I do my current job better?
  • Some just want to learn from other people’s failures and their successes.


Usually, you don’t go from not being a mentor to being one. It’s a progression. Someone asks 1, 2, or 3 questions and then the relationship evolves into a mentor / mentee relationship. Mentors can sometimes “pattern match” meaning that they can apply solutions that they have learned through other contacts. Mentors can create a general solution framework. The more the mentor can create those kinds of things the more people will want to reach out to you. It’s important to make it clear to the mentee what it is you want out of the relationship. Otherwise, it’s a one sided relationship. Both parties must understand each other’s reasons so it is win / win.

Not all mentors are the same. The good mentors will actively reach out to their mentees. It’s on the mentor to provide actionable and real world information. Theory needs to be backed up with practicality. How they communicate and how often can be dictated by what is currently going on for the mentee. The example given is around stakeholder communication. That might require frequent phone calls from the mentor. The communication should be constructive and direct.

Good mentors have a network. They proactively send out articles to the mentees that may serve them well. They can tap their network for answers they don’t know.

Best Mentor / Mentees Matches And Linking Up

An ideal mentor has worked with many employees that went from career spot A to career spot B just like the mentee wants to do. So, how can a product manager connect to a mentor?

Can start small. LinkedIn and other sources of groups. (User groups in town or online groups?) If you are seeking UX, Behance or other sources are discussed on Quora.

How To Approach The Mentor?

Say you are impressed by what they are doing. Tell them it would be helpful for you if they could advise you on this one specific problem.

People are sometimes happy to do a 20 minute phone call. Offering a free lunch can be good.

Good Questions To Ask

Good example of a specific question to ask is something tangible. Something like you are faced with a specific challenge. For example, you want to communicate the roadmap to the sales team better. Right now, there is a mismatch. What are some best practices in this specific situation?

An example of a bad question is like “What are the three most important things for a product manager”? It’s not actionable because people work with different constraints and issues.

In Ben’s career, he got mentors that helped fill gaps that he had. His “council” of people that he could go to consisted of CEOs, VPs, VCs, investors, and so on.

Stay in touch with your network. Over time, it’s amazing the value the network will provide.

If Ben Could Change Something

A mistake he made: He spent a couple of years making incremental improvements. He looked back two years later and asked himself “what did I really build?” “Where’s the innovation?” Getting leapfrogged by someone else is bad. The specific example is eBay vs Amazon. It’s like they “Won the battles and lost the war”

Ben is Reading


As you can see above, the Mentorship is Product Management podcast episode is filled with great advice when it comes to understanding, defining, and establishing mentor / mentee relationships. I highly recommend you listen to the podcast as well as the other podcasts at This is Product Management.