The “Tim” story

I had the chance to work on a discovery sprint recently. During this two-week sprint, I revisited a bunch of agile delivery fundamentals in a way I haven’t in a long time. The project was suffering from some of the great, classic mistakes of software delivery we all know and love such as working in silos, internal politics, inability to deliver anything into production, finger pointing, comments like “we tried agile and it didn’t work” and so on.

Our discovery sprint team started using an example we called the “Tim” story. Tim is one of the executives in charge of the project.

After doing twenty user interviews, looking at code and reading a business case and other artificacts, one of our findings was the project was using a waterfall approach to manage a project with complex business rules, an ERP system. The team would talk about insufficient requirements and failing tests. Everyone was blaming each other.

Our recommendation was for Tim to be migrated out of the old system into the simpliest version of the new system that could be deployed to production. Because the team were working in silos, they had accomplished a great deal in their own silo but nothing worked together thus zero business value had been delivered in two years of working on the project.

Tim would receive his paycheck from the new system and if that failed, he could receive a handwritten paper check, bugs would be fixed and we’d try again two weeks later. Because Tim as an employee is one of the simplest payroll scenarios, the salaried employee with no special circumstances, we described this to the team as “the happy path”. Once Tim was being successfully paid by the new system, the entire management team working on parts of this project would be migrated. This is a way to deliver small iterative value while also demonstrating how committed the executives and team members are to the effort.

Now, a lot needs to happen before Tim can get his first paycheck. The system needs to be deployed to production, how a single employee is migrated from the old system to the new system needs to be understood, there needs to be confidence in the basic security of the production system and more.

As additional groups are migrated, the complexity will increase. For example, an employee that is working two different jobs with overtime and several dependents. They split their paycheck into several bank accounts and had previously worked at the company, quit and has now returned to their old job.

The team should take these complex use cases that the new system needs to support, focus on them as a team one-by-one and see success. They should continue in this “continuous improvement” phase of the project as new groups of employees are onboarded.

Contrast

Now, contrast the “Tim” story with the project team’s current way of working. For over two years the team has been assembling a complex list of never-ending requirements aspiring to a place where “we have all the requirements” (unrealistic) and “we have confidence the system works for all HR and payroll complexities” (impossible) and “then we can do a big bang cutover to the new system” (dangerous).

When our discovery sprint team talked about the happy path versus waterfall big bang approach in our readout it resonated with the whole team. You saw head nods from non-technical folks, agreement and understanding from Tim and validation from others saying things like “We tried 5 test cases six months ago and they all failed but they were our most complex payroll scenarios involving overtime pay, employees working two jobs and more. We never thought to start simple. This totally makes sense.”

In past products I’ve worked on, I’d tell a very similar story about “how we can take the first $1.” Executives would often scoff at this and talk about how we need to support millons of dollars of revenue and get inpatient. However, it’s powerful. Understanding the first simple flow, the happy path, the MVP, etc is still a great thing to lean on if you are trying to help unstick a giant enterprise project or working on your next small startup.

Creating Momentum in Product Management

As a Product Manager, shipping and launching are always on my mind. Here are a few techniques I’ve used over the years to create momentum and keep the team excited about making progress and aligned on our ship dates and goals.

The big conference launch
I don’t love the “hit a date” tactics in product management but have used a big conference launch to generate steam successfully a few times. We did this with the launch of the CMS Blue Button API last year. When you have a big opportunity to generate press, attention and a bunch of new users / customers, it’s worth it. If you take this approach, make sure it’s a team decision and be ready to compromise a lot to get things shipped so you hit the date. You need to fundamentally appreciate how much teams hate having a date dictated to them and be an equal member in the quest. You are in this together. Also, be ready for tons of other non-software type work like doing press, building conference materials and being in a bunch of meetings making the various executives and stakeholders feel comfortable that the launch is on track.

Iterating towards the big vision
I know agile development is all about shipping working software, incremental pieces of the big vision. Sometimes it’s hard to get this train rolling. One of the approaches I’ve used a lot is getting the basic deployment pipeline setup early to deploy “hello world”. Once this is going, don’t be afraid to deploy tiny pieces. It will gradually build momentum.

If your product is stuck in some frustrating planning or architecture phase, try to find a way to keep moving forward. Can’t decide on a complex architecture? Try shipping a super simple user survey you can circulate around. How about shipping a basic piece of plumbing you are sure will be used in the product. Especially in the enterprise, my experience has been this really matters. Go a few cycles without shipping anything and the team will slow down to a crawl and morale drops. You’ll be having conference calls to plan the next conference call.

Intrinsic motivation meets good product goals
Luckily, most of the teams I’ve worked on over the years have a common understanding of the product goals and are motivated as hell to see the vision realized. In this environment, a PM needs to clearly articulate the goals and talk about how they are realized over time to give the team a good sense of the road ahead. If the team stalls, it’s usually the PM’s fault. Some decision is not being made and the path forward is not clear for the team to execute.

Summary
Good luck in 2019, I hope you build amazing things for people. As a PM, you know when the momentum isn’t there. Maybe you feel it yourself, the passion is gone and you aren’t obsessing about the product you’re building. Maybe the team feels broken and there are a million reasons why you can’t make progress. Hopefully if you find yourself in this state, you can use some of the techniques above to create momentum and ship!

Additional reading

The definition of “going live” – lessons from PivotDesk in 2012

Featured image from Undraw.

Screencasts for Product Managers

Screencasts are easy to build and a great way to convey information.  As a Product Manager, being awesome at communication is a big part of your job.  Can you tell a great story to customers?  Are you articulating the product roadmap to your company?

I have used screencasts to:

  • Demo a “Getting Started” experience on the website
  • Show off the product at a conference booth
  • Give product updates at Board Meetings
  • Describe the customer journey for a new product to team members
  • Help sales reps communicate with beta customers
  • Announce new product features on blog posts
My setup is:
My workflow to build a screencast is:
  1. Open Byword, type out a 1/2 page script (5 min)
  2. Grab scrap paper and pen, sketch a storyboard of the screencast (2 min)
  3. Plugin USB mic, open Quicktime Player and record the audio a few times to get the pace and tone of your voice sounding right (5 min)
  4. Open Screenflow, import the audio track. (1 min)
  5. In Screenflow, click record and capture video of your screen following along with the storyboard you sketched.  Do this a few times to get it perfect.  (5 min)
  6. In Screenflow, edit your screencast adding call outs, transitions and titles. (15 min)
  7. In Vimeo, go to Create / Music Store and search for an instrumental background track.  One you find one, download it and import into Screenflow.  Adjust volume levels of your voice track and the instrumental track. (10 min)
  8. Export your screencast to Vimeo (2 min)

Total time: 45 min

Tips

In Vimeo, there are a few helpful settings under “Privacy”:
  • password protect your video to share with a select group of people
  • set “where can this video be embedded” to “only on sites I choose” if you only want the video available within your app for example

I’ve used my iPhone to record a few seconds of people around the office, people in front of a whiteboard or monitor, etc.   If you are building a screencast to tell a customer story this can work well.  Plug your iPhone into your laptop and import the clip into Screenflow.

Examples

Further Reading

How Product Managers Can Mess Around With Open Datasets

Most Cities, States and Federal Agencies are working on some type of Open Data initiatives. The most common is an “Open Data Portal” that makes it easy to grab and use datasets:

https://data.cincinnati-oh.gov/
https://data.colorado.gov/
https://data.commerce.gov/
https://www.data.gov/

Some cities are using Open Data to publish performance metrics like the Seattle Police Department or Louisville’s LouieStat.

Civic Leaders working on these initiatives cite promoting transparency in Government, improving performance and providing data for innovation as reasons why Open Data is so important.

As a Product Manager, it’s helpful to be familiar with what’s out there and how you can play around with these datasets to better understand how your product may benefit.

Before you dive into querying APIs, checkout a few of these projects to see the end result of building something with Open Data.

USAFacts
CollegeScorecard
500 Cities Project
Data.gov

Ok, now let’s dig into some datasets you can play with.

Socrata’s Open Data Network
Socrata hosts over one hundred different data catalogs for governments, non-profits, and NGOs around the world. Checkout their Open Data Network where you can search for datasets.

For example, here’s a page about San Bernardino County Employment. Click “View API” to end up on a page giving you data and an API call you can paste into your browser or Postman.

Namara
Namara has organized a bunch of public datasets into a beautiful UI. Create a free account, sign in, create a new project then click Open Data in the left column to search and add datasets to your project. You can view the table data and manipulate it or call the data using their API.

https://api.namara.io/v0/data_sets/{DATA_SET_ID}/data/{VERSION_ID}?api_key={YOUR_API_KEY}

In your project settings, you can generate an API key. Then, in each dataset you can click “API Info” and get the data_set_id and version_id.

ProPublica
You can use ProPublica to request data about Congress such as a list of Recent Bills and Member Voting records.

https://propublica.github.io/congress-api-docs/#congress-api-documentation

You’ll need to request an API key by emailing apihelp@propublica.org then pass that in the X-API-KEY header.

For example, to query Rep. Jared Polis’s voting record:
https://api.propublica.org/congress/v1/members/P000598/votes.json

Open Data and the big IaaS Platforms

Another approach is to checkout Public Datasets baked into AWS, Google Cloud Platform and IBM Bluemix.

This is a great example of using Google BigQuery on NYC Public Datasets.

AWS hosts a bunch of Open Data in S3 buckets.

IBM, as part of the NOAA Big Data Project, has built an easy way to download tons of data.

Additional Reading

A few hashags to search around on are #govtech, #opendata, #opengovdataand #opengov. Follow people like @Josh_A_New, @JoshData, @DataInnovation, and the @SunFoundation.

Here are a few links related to Open Data policy and relevant news.

Some history on U.S. Federal Open Data Policy

DATA Act passed in 2014, America’s first open data law. It directs the federal government to transform all spending information into open data.

Conversation on the future of Open Data as Administrations change and the Preserving Government Data Act of 2017

The OPEN Government Data Act “directs all federal agencies to publish their information as machine-readable data, using searchable, open formats and requires every agency to maintain a centralized Enterprise Data Inventory that lists all data sets, and also mandates a centralized inventory for the whole government (data.gov)”.

Open Data 500 US is an interesting survey results showing what kinds of companies use which agencies’ data.

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

Thinking about Enterprise Software Startups

I ended up down a rabbit hole of research on Sapphire Ventures thanks to the Origins (Notation Capital) podcast on my flight home from Boston early this morning. Sapphire invests in Enterprise software companies. I got to thinking, if I were to analyze companies in that space with my Product Manager hat on, what would I look for?

These 5 areas came to mind.

1. How will the Product interoperate?

Ex: Zapier, BI fabric, Hybrid Cloud

Is the team thinking about how to move pieces of data around from their app to other apps, from their app to the Enterprise systems, between their Public Cloud and the Enterprise’s on-prem and Dedicated Clouds?

How will insights and raw data from their product be accessible to the Enterprise’s BI Fabric, Data Scientists, etc? How does that strengthen the value of the offering?

2. Where are Users interacting with the Product?

Ex: Mobile, APIs, Slackbots, Echo

Is their product enabling all types of Users to be engaged anywhere? Is extension of the product easy by a Customer Developer via APIs? Is there potential for an Ecosystem to organically grow around the product? Does it feel like a Platform? Is the pretty Mobile app for the on-the-go Sales person just as well thought out as the Developer API?

3. What are the Combinatorial Effects?

Ex: Exongenous Datasets, Data Network Effects

Is the team thinking about combining datasets together to create something new? Does the product have inherent data network efforts? As more people use this, will the value increase?

What two features used together accomlishing something really powerful?

4. What role does analytics play?

Ex: NLP, Computer Vision, Salesforce Einstein

Enterprise data is flowing through the product. How is that data being mined into features? How are signals being extracted using NLP, Computer Vision, Machine Learning, etc? Does the business analysis get smarter the more people use it? Does AI feel like a foundational part of their approach or do they think of it as gimmicky and a nice-to-have?

5. Talk about the Tech Stack

Ex: Microservices, Serverless

Is the team using technologies like AWS Lambda? Do they talk about Reference Architectures and Blueprints? Are they taking a Microservices-first approach?

A few more articles I came across while writing this post:

It’s fun to think this stuff through. I remember the days of meeting with investor after investor while in Techstars and how many of those conversations led to strategy and product improvements.