What I Want To See From Evernote in 2017

I have almost all of my strategic thinking, articles I’ve found useful and reference material in Evernote. Their browser extension works great as does their Mac, iPad and iPhone apps. I even have the WSJ integration enabled so I see relevant news with my Notes.

It’s time for Evernote to not only store my information, but really help me be smarter and better at everything I do.

I would happily opt-in to this feature giving them access to learn from my personal data as long as I had a mechanism to “mark Notes private” which would exclude them from Evernote’s Machine Learning activity.

Given a seed list of Notes or a Notebook, I want Evernote to help me:

  • Monitor important news and activity from Companies and People I’m interested in
  • Show me correlations and visualizations in my Note data so I can better connect the dots and broaden my context
  • Suggest actions I should take based on my Note data

Evernote knows the Companies, People and Topics I’m interested in. Their browser extension could contrast my browsing behavior and work style with what I save into Evernote to learn more about me. They know my travel habits based on where I save Notes and all of the travel data I store in Evernote. They know about my kid’s activities because of the receipts I save, they know the gift idea list I’m keep for my upcoming 15th wedding anniversary.

Example:
I want to build a list of Venture firms funding healthcare companies. I know that Mattermark and CB Insights have these by segment, but I want my own list and to apply my own logic. I want to understand all the people that work there and what they are talking about. I want to know about their investments. I want to know when people leave the companies. I want to dig deeper and see trends using visualizations, etc.

I have been to the Evernote conferences, think Phil Libin was a visionary leader (#selfie) there and continue to be a paid user of the product. I’m hoping 2017 is the year that the Evernote team blows my doors off.

The First 90 Days for a Product Manager New To Healthcare

I talk to Product Managers all the time that are considering building products or features that would move them into the Healthcare space. This post is for them.

As you venture into Healthcare, you are embarking on the most TLA filled space imaginable. Talk to other Product Managers that are veterans in the space and you’ll barely be able to follow along. They are not trying to sound smart, it’s simply that the TLAs get ingrained so deep that it takes real effort to not use them.

You’ll also come across a few big topics like:

  • How regulation impacts business models
  • Selling into large Healthcare organizations
  • HIPAA and GxP
  • Healthcare and Life Sciences are very different

I began my first 90 days as a PM in Healthcare on a beach in Florida with my wife and kids on Thanksgiving break. I lounged around reading/listening to these 3 books:

Doing this gave me an understanding of the ACA, Pharma and all of the problems especially in the US Healthcare system. I was beginning to understand some of the TLAs.

My next step was to talk with other Product Managers. I had to ask a lot of dumb questions in these conversations but everyone was super nice and helpful. #givefirst These conversations helped me build a list of news, people, podcasts, blogs, etc that now make up my daily healthcare and biotech information pipeline. On a daily basis I found myself reviewing the Healthcare Top 100 and thinking about the business models of these companies. I subscribed to daily healthcare industry news from Becker’s Hospital Review, STAT and Modern Healthcare. I followed Zdogg and David Chase on LinkedIn. I listened to podcasts from Catalyze.io and a16z.

At this point in my first 90 days I was back in the office, still under a nice “you are still new” grace period and learning from everyone I could. The next step was to talk to Techstars Alumni, Denver-based Founders and friends of mine that are running Healthcare Startups. I had 50 conversations in two weeks and summarized most of them in a shared Box folder the team uses. For a handful of the conversations, I summarized and sent an email to entire team to raise awareness. This quickly established me as the expert for our “Healthcare Startup Developer” persona.

In the first 90 days:

  • Tell stories to build empathy about the people the product is trying to help.
  • Establish yourself as the voice of the customer on your team.
  • Show you are passionate and curious about the problems to be solved and the people you are trying to help.

It’s been one year since I began my journey as a Product Manager in Healthcare. I am once again sitting on the beach over Thanksgiving break pondering our Product Roadmap, Industry trends and reading everything I can about AI in Healthcare, Big Data Analytics use cases, Serverless Compute, how the ACA may change in the next Administration, CRISPR and more.

If you want help with your first 90 days, please don’t hesitate to reach out….and good luck!

Photo Credit: https://unsplash.com/@joaosilas

Using Trigger Lists in Product Management

I’m a big fan of “trigger lists”. The exercise of building them and the value they bring to a Mind Mapping or Design process have proved beneficial to me over the years. One of my favorites is David Allen’s GTD Incompletion Trigger List.

Recently, I transitioned from obsessing over providing Developers with APIs that would help them build amazing things with AI to obsessing about Healthcare and how AI can provide better care while lowering costs.

I pounded a Doppio and spent an hour brainstorming this trigger list to help me empathize with Users and better understand Actors in the crazy ecosystem that is today’s Healthcare tech.

I am a…

Healthy person
Cancer survivor
Farmer
Factory Floor Worker
CRO Administrator
CIO
CFO
CEO
Developer
Product Manager
Auditor
Patient
Physician
Nurse
RN
PA
Administrator
Researcher
Daughter
Son
Parent
Community Oncology Clinic
Hospital CEO
CMS Employee
FDA Committee Member

And I have…

Outcome data
Clinical trials
Drug databases
Medical journals
App Store Reviews
Medical Devices
Demographics
Avatars
Full Contact API data
Clinical Trial Participants
Patient data
Lab results
Population data
Reimbursement data
Patent filings
Hunches
Students
Research and Health kit data
Hospital trends
Emails
Tweets
Blog posts
Survey results
Internet searches
Essays
Product reviews
X-rays
Photos
Instagram searches
A list of questions

And I want to…

Find Patterns
Organize my data
Filter my data
Search my data
Understand social media
Build an Android app
Surface correlations
Have access to information

So I can…

Comply with regulations
Stay up-to-date
Collaborate with a Physician
Track my progress
Get credit for a course
Be reminded of an appointment
Find cost savings
Sell an app
Make people healthier
Prove a point
Get reimbursed
Understand health trends
Track my Clinical Trial
Find a Hospital
Research and buy my medication
Predict outcomes
Make more money
Connect data together
Build a treatment plan
Find a Clinical Trial
Predict the Future
Support Meaningful Use
Make evidence-based clinical decisions
Analyze adverse events
Provide better treatment “in the field”

For those familiar with Agile, you’ll recognize the “As a User I want” format of this trigger list.

We all have so much stuck in our heads, try creating one of these trigger lists for something in your world and you’ll be surprised at how it can help.

How GTD Areas of Focus relate to Product Management

One of my favorite GTD concepts is Areas of Focus. Using Areas of Focus in your personal productivity system helps group work into context. No need to look at todos like “Get House Painted” when you’re at work. It’s better to look at only work related stuff that you want to be focused on.

For the longest time I’ve had Areas of Focus like House, Family, Marriage, Gear and Travel. I had one Area of Focus for work called PivotDesk. Inspired by a recent webinar on GTD Connect given by David Allen, I decided to refine my work-related Areas of Focus.

Old: PivotDesk

New: Product Management, Feature Development, Product Performance, Product Marketing

As I went through this exercise, I had a chance to think through the different types of work a Product Manager interacts with to get the job done.

Product Management
Idea management, sprint planning, processes, team, budgets, timelines, product roadmaps, internal communication and demos.

Feature Development
Scoping, customer interviews, idea validation, wireframes, designs, details and QA.

Product Performance
Instrumentation, A/B testing, analytics and KPIs.

Product Marketing
Product tour, blog posts, inbound channels, segmenting visitors and drip email campaigns.

I’ve found each of these areas requires a different headspace, pace and communication style. When focused on Product Management, my head is very much in business and planning mode. I’m emaliing, looking at the calendar and updating people. When focused on Feature Development, I am putting myself in our customer’s shoes, feeling empathic and brainstorming ideas. I’m staring at personas and drawings taped to the wall and getting whiteboard marker stains all of my arms and clothes. I’m far, far away from my email and calendar.

What do your Areas of Focus look like?

Building Software is Amazing

For the past 6 months I’ve had the opportunity to work on one of the best projects of my career.  This thing has all the buzzwords: big data, social media monitoring, semantic analysis, kanban, ruby on rails, github, distributed teams, expertsourcing, skype video, lean, pragmatic, platform, you name it.  The team is brilliant and highly skilled in their areas of expertise (rails programming, UI/UX development, architecture).  Each member cares deeply about their craft and is highly passionate about our project.  We argue, we collaborate on great ideas, and all stress the difference between opinions and facts.

This quick reflection just reminds me that building software is amazing.  It’s not writing up exhausting requirements that no one cares about, it’s not outsourcing all of your technology to a vendor, it’s not making stupid decisions that leads to wasting money and not shipping product.  Building software is about being creative, respecting the craft and the team and adapting quickly to a changing environment while relying on tried and true principles.  I can’t wait to see what shows up in the next “git pull”.

Review of Do More Faster by David Cohen and Brad Feld

Looking at my book shelf organized with business books, seeing my iPad filled with iBook samples and seeing the New York Times Sunday edition laying around would make you think I’m a big reader.  In fact, I’m a fraud.  I’m the person that likes to start lots of books, read for a few minutes at a time and hardly ever finishes a book.  I pre-ordered Do More Faster by David Cohen and Brad Feld and read it from start to finish the day it arrived.

Do More Faster is divided into 7 Themes: Idea and Vision, People, Execution, Product, Fundraising, Legal and Structure and Work-Life Balance.  Within each Theme are several 1-3 page stories written by Entrepreneurs, VCs and other interesting people in the software, internet, product development, startup realm.  It’s a great format for the hyper caffeinated, ADHD, check twitter while your reading type of personality.

This book was fun for me to read because many contributors are familiar faces I either work with in some capacity or have seen around the flourishing Boulder/Denver tech community.

Chapters that blew me away and taught me something brand new:

  • To 83(b) or not to 83(b), There is No Question – Matt Galligan
  • Usage is like Oxygen for Ideas – Matt Mullenweg
  • Karma Matters – Warren Katz
  • Don’t Plan, Prototype – Greg Reinacker

Chapters that reinforced some of my favorite work related topics:

  • Don’t Suck at E-mail – David Cohen
  • Get Out from behind Your Computer – Seth Levine
  • Be Specific – Brad Feld
  • Get Feedback Early – Nate Abbott and Natty Zola

If you want motivation for anything you are doing I highly recommend Do More Faster.

Why GTD Projects and Agile User Stories are so similar

David Allen’s Getting Things Done (GTD) approach reiterates the challenges of breaking a Project down into Tasks.  He focuses on the psychologic barriers people have with the work in front of them.  A common example (I’m paraphrasing here) is a person adding “Mom” to their ToDo list.  When digging further, David discovers that “Mom” really means “Mom’s birthday is coming up” and there are no Tasks or “Next Actions” defined to move the Project closer to completion.  This avoidance is very stressful on the person and a very inefficient way to life a busy life.

We use Rally’s ALM product and the Kanban custom tab to manage our User Story development.  I have worked with 2 teams over the past few years and both I consider quite amazing and talented.  Ongoing debates about naming conventions for User Stories, the importance of Tasks, and who should be the Story Owner have never been resolved.  Our teams crank out great software, but always within a stressful environment.

As I was enjoying a nice bike commute into work last week I was listening to the GTD | Podcasts episode titled “The Do Lectures”.  Around minute 10:30 David Allen says that to clarify anything, you have to decide “What outcome are you committed to finish about this?”  I realized how similar GTD Projects and Agile User Stories really are.

  • A GTD Project clarifies the outcome you want.
  • An Agile User Story describes what the User wants to achieve.

Both GTD Projects and Agile User Stories use Tasks as a method of describing the work required for completion.  In both, Tasks probably need to come in some sort of order, will vary in their scope and may require different people’s resource.  Also in both, if Tasks can be defined it signals a complete understanding of the work to be done.  Granted, you may have missed something, gotten something wrong or encounter changes along the way, but at least you’re on the right track.

My experience in working with fellow Developers is that being asked to Task out a User Story is sometimes treated as some kind of insult or waste of time.  We joke a lot about a common Task name we use in Rally simply titled “do it”.  Again, the GTD project similarities are strong here.  The initial reaction is to keep things in your head and resist verbalizing the steps required to complete the work.  Instead, insist on breaking every User Story down into Tasks and agree that the first Task to be worked on or “Next Action” is the most important one.

By leveraging the GTD Projects similarities in your Agile team, hopefully everyone will be more efficient and less stressed!