Meetup Documents – User Personas

We recently had a meetup event where Kyle Weiss talked about Persona definition for consumer apps. He walked through the process of initially defining a persona and then how to refine and re-evaluate once you have had a chance to validate assumptions with data. The slides and personas he presented are attached.

Slide deck – Workshop – Personas_posted

Persona 1 –

Persona 2 –

One thing to note, this process was geared towards new concepts and new ideas and should be modified for existing B2B orgs or where a business already exists. Understand who your paying customer is, will always be more important than trying to define who they “should” or “could” be.

What is Growth Hacking

There is a relatively new term cropping up in software companies called, Growth Hacking. Some organizations are hiring a Growth Hacking team. But, what does this team or person do and why should you care?

Growth Hacking is a relatively new concept of building a very lean team (sometimes it’s a team of one), that is focused on experimentation and rapid iteration to improve the weakest link in a sales/UX/marketing funnel. These teams usually have a Product-esque person, a strong Marketing-esque person and at least one Data Scientist/Analyst, and sometimes even an Engineer. Usually a single person is not enough to fill this role, but it’s possible in a pinch (it’s never a great idea to say a single person team will be successful). Here is what those roles are really charged with doing:

Product-esque person is looking at product engagement metrics, for a consumer app, that may be registration rate, time in app, % to purchase or upgrade, churn rate, etc. For a business-focused app, it is the reduction of time in app, net promoter scores, customer support requests, etc.

The Marketing-esque person is looking at the funnel(s). They are analyzing the ad campaigns, the install rates, the success rate on converting from a white paper, etc. They need to be reviewing every marketing effort and understanding what is valuable and what is costly noise.

The Data Scientist/Analyst is looking at the trends in an app, they are helping refine personas (based on the data they see), they are helping showcase app usage metrics (perhaps from Google Tag Manager, or Mixpanel), they are working to ensure everyone is looking at the same key metrics and they are helping identify which key metrics to focus on next, while proving insight into how the current tests are performing.

The Engineer is the one who can help prototype and rapidly iterate through changes. They are usually tweaking and refining small aspects of the product, helping build experiments that have measurable results and are the enabler of the team.

The real responsibility of the growth hacking team is to review every aspect of your user acquisition funnel  – first contact with a user to the final “conversion,” whatever your company deems the success criteria. This team is in charge of making changes throughout the entire process to quickly and dramatically drive improvements. They should be spending just a couple weeks refining and prototyping these solutions, and relaying feedback back to the respective owners on how to make a “long term” implementation, if they don’t do it themselves (you often don’t want this team rolling out changes that will live forever… they are probably using tools like Optimizely to “hack” in tests). They are analyzing the data of what is working in the workflow and what is not, and they are focusing solely on the weakest link in that experience. They should be quantifying the impact of the improvements they hope to make and setting ambitious goals (start with industry standards if you are not on par with those yet) that will move the needle.

Ultimately, you need these people – you need this function in your business. Even if you cannot hire a dedicated team, you need people covering these roles in some form or fashion. If you can have a team focused on Growth Hacking as part of a normal sprint, or a normal marketing cycle, you will dramatically improve your product in a way that keeps you ahead of the competition.

Check out the post that talks about how to make quantitative product decisions, it dovetails nicely with this :)

Product Podcasts

Guest Post :: by Alex Haar, Head of Product Management at ZestFinance

As a follow up to the previous post about reading materials for new product managers, here are a few podcasts that hit on the subject of product management and startups.


Read their book, read their blog, listen to their podcast. These folks really get product management and they can articulate both the strategic and tactical aspects in a wonderfully clear and actionable manner.

This is Product Management

Alpha UX created this podcast to cover the many different disciplines relevant to today’s product managers. As described by them, they take a “deep dive into user experience, statistics, innovation, differentiation, design, development, metrics, and more.”

Product Hunt Radio

Product Hunt is a place to find new & interesting products, curated by the people who are passionate about products & technology. Product Hunt Radio is founder Ryan Hoover’s podcast where he “geeks out” about products with the people who create them.

Product People

Justin Jackson stays quite busy. Don’t believe me? Check out his profile. One of his newer projects is the Product People podcast. Justin has a wide variety of interesting guests, including Nir Eyal (author of Hooked) and Samuel Hulick (creator of User Onboard).

The Rocketship Podcast

While not strictly about product management, this show about startups covers many topics relevant to product managers. There are tons of great episodes to listen to with great topics ranging from “Your Strategy is Your Story” to “Customer Interviews Done Right”.

Path to PM: Michael Lynch

Breaking into a product management career can be a challenging endeavor and the “best” or most “straightforward” method to do so is largely undefined.  Product Management is often referred to as a role that is learned through experience rather than taught in the classroom.  “Path to PM” is a blog series highlighting the many diverse, interesting and unique paths the writers have taken to become a Product Manager.

Michael Lynch is Vice President of Product at Envysion and a member of the leadership team of ColoradoProduct.  Michael’s product management career spans successful start-ups and large corporations in multiple countries including Switzerland, The Netherlands and Saudi Arabia.  Michael holds a B.B.A. in International Economics and Management Information Systems from the University of Oklahoma and the Hochschule für Ökonomie in Berlin.

Like most, my path to product management was a surprising path, at least surprising to me. As a 16-year old, I was sure I would be making movies for a living.  As a former 16-year old, I now realize I’m doing what I was meant to do.

There are four threads I can follow back through my early years:

  1. Innate fascination with products and technology
  2. Entrepreneurial spirit
  3. Wanting others to find value through my products
  4. Maker mentality

As a kid, I disassembled every ‘dead’ electronics device within hours of its demise.   My family suggests this was my basis of wanting to understand ‘how things worked’, which is one central ingredient, I believe, in having a natural tendency toward being a product manager.

In Middle School I would buy large 50-count bags of Hubba Bubba for a couple bucks and sell individual units to fellow students at $0.5o a pop. I was providing a valuable product at a reasonable price. The school, however, disagreed and my budding business was banned after only two short weeks.  

The third thread is best summarized by an incredible engineer and friend – Vince – who I was trying to retain with additional money during one of our startup’s downturn during the first bubble-burst. Vince told me “It’s not about the money. What I care about most is that the stuff I write gets used by real people…that it doesn’t end up on a shelf somewhere…and, that users get real value from using it.” Knowing I am creating real value for customers is what keeps me interested and dedicated to an effort. It’s how I’m wired. I have to know the true value of my product.

A fourth element that drove me to product management is a need to create things.  Whether it be art, music or software, the best product managers are creative and have a desire to build things.

So how did these four innate drivers influence my life in a way I couldn’t control?

First was college.  What would a person with these interests study at university?  Depends on who is paying.  Since my parents, scholarships and the US government were all paying I decided a Fine Art degree with a major in Film Production was the obvious choice.  My mother was on-board… with one caveat:   I double-major in business and/or engineering. Seemed like a fair compromise.  During my sophomore year I did an internship at McCaw Cellular (later acquired to become AT&T Wireless).  Seeing that their sales folks were still calculating commissions on paper, I found it fun to write a commissioning app.  I did it for fun.  It was a hit in the local office, then adopted regionally and then finally nationally. Two key takeaways for me:  1) that was a lot of fun!; and  2) I realized I created a lot of value — but just wasn’t compensated for it very well.

My first real job after college was working for Morris Information Systems. They needed someone young, unmarried and slightly crazy to open the first NeXT VAR in the Middle East.  At the same time, M.I.S. was building custom client/server software for Saudi Aramco.  Before I knew it, I was managing a dozen engineers in Saudi Arabia, representing Steve Jobs’ new company and convincing the COO of Saudi Aramco to build an oil trading app on the NeXTstep platform (at a time when Sun Microsystems was the only game in town).  This experience gave way to a few key takeaways:  

  1. This also was a lot of fun!
  2. Understanding and guiding your customer is fundamental to success.
  3. If you dream big, you can represent a small boutique custom software shop and get a deal with one of the largest, multi-billion dollar companies on the planet.

While in Saudi Arabia, I met someone who would become my business partner (here in Boulder, Colorado) across two venture-funded startups and two corporate-funded autonomous organizations.  He gave me the opportunity to be an equity shareholder on the ground floor of the two start-ups and the role of “owning the product.”  From there, it was off to the races – building, making and trying my best to focus on providing value.

Over the next ten years we built the first organization dedicated to object-oriented client/server applications within SHL Systemhouse, partnered with NeXT Computers, Inc. to help bring client/server apps to the emerging World Wide Web, sold the company to MCI and then created the same exact thing all over again for Swiss Bank in Zürich.  In 1995 we got the chance to build our very first, fully-owned start-up, Avolent, Inc. (after three name changes and one merger) and our first true “Internet application” product, an electronic bill presentment and payment platform we sold to MCI, Wells Fargo, OfficeMax and many others.  Over this period, as we grew from seven founding members to over a hundred employs, I learned more about product management and building a business than I could have ever hoped.  The key takeaways are too many to count, but all of them point back to those same key early drivers.

These forces are irresistible and highly rewarding emotionally.  I would sum them up as…

1) a desire to understand ‘how things work’

2) a need to be creative and to ‘create things’

3) a desire to provide real value to customers (as affirmed by them)…

4) …and make money while doing it as a real business


Building solutions versus solving problems

Building a solution is the same thing as solving a problem right? You need to build a solution to solve the problem, there is no way to solve the problem without building a solution!?


At many organizations, product teams are branding themselves as the team who is focused, almost exclusively, on building a solution. They are focusing department goals around building solutions to problems the business has a core competency in solving. This sounds terrific in theory – we are solving a problem by building a solution in a market, we are experts in, while focusing on our competitive advantages. We have taken into consideration our competitors and we have a value prop that is unique differentiated. The real focus needs to be on solving the problem, not building the solution.

The problem comes from the idea that the only way to solve a problem is to “build” a solution. Perhaps you have heard of this example, NASA set out to solve the problem that current pens didn’t work in space. They spent millions to have a pen built that would function in a zero gravity, low temp environment. The Russian cosmonauts on the other hand simply brought pencils and avoided the millions in R&D. Though this story is not actually true, the principle rings true and is very often lost among product managers.

There is a large pressure to find the next billion dollar idea and to build a solution which will solve or up-end a market or solve a problem the world didn’t even know it had! This is a noble feat to undertake, just make sure you are focused on solving the problem and not building a solution. Hulk Hogan endorsed a “solution“, while George Foreman endorsed a product that solved a problem. Homeland Housewares (and others) would later iterate on the Hogan endorsed product, and they actually were able to solve a problem with the new design. The point is, really evaluate a problem and make sure your solution solves the problem, don’t just build a solution – solve the problem.

Joining forces to pursue common vision!

It is with great excitement that we welcome the members of the Front Range Product Management and Marketing Meetup to the Colorado Product organization!  Through discussion with the leadership of that meetup group, we at Colorado Product quickly identified alignment in the goals and mission of both groups.  Given the aspirations of both organizations to support and grow the practice of Product Management in Colorado, we determined that consolidation of our efforts and initiatives would maximize impact on the Colorado product community we support.  Thank you to Travis and Pramit for the work they have put into launching and building the meetup! We are excited to bring you and your members into the Colorado Product fold.

Adam Tornes
Director & Co-founder, Colorado Product

Product Roles: The Role of a Director of Product Management

We continue our series on Product Roles and how each role varies, while focusing on the work each Product role can play in an organization. Please keep in mind, product team’s responsibilities can be highly varied. Some organizations have parsed these job functions to other roles, sometimes across departments. The success of that parsing will vary from company to company. In this series, we will focus on what we feel the roles entail in a “typical” product organization.

In this third post of the series, we dive into the Director of Product Management role.

From our first post in the series:

Directors of Product Management look after the business of product management. They usually help oversee the cohesion of multiple product/service verticals and they should be the guiding light on the process and tools used to report the product team’s direction. They are the stabilizing and negotiating hand that ensure teams are operating with synergy. They know when to step in to support a Product Manager and they, most importantly, know when to step back from the Product Manager to let her flourish.

These people have two essential responsibilities. First, they must build a strong team of product managers. Second, they may be responsible for the company’s overall product strategy (if there is no VP) and more commonly, they oversee various products in the company’s portfolio.

The director of product management is really an enabler, mentor and one who often brings process. Their job is to guide, and remove roadblocks while establishing expectations and goals. Directors need to trust in their PM’s ability to execute and the director needs to be the uniting force that ensures their success. This role is one with influence, but often less “power” than the PM has on the product.

Establishing process, building mentor tracts, and championing learning are often some of the primary responsibilities a director will have. The key is to recognize the shift from a doer to enabler.

A typical job description for a Director of Product Manager often includes (with some added company specific, cultural fit type requirements):

  • Providing product portfolio management, mentoring and training Product Managers in best practices, and managing products as needed to support the company’s strategic goals.
  • Owning the end-to-end Product and Solution portfolio and associated financial performance with a P&L orientation.
  • Providing leadership for the product development process across Sales, Marketing, IT, and Operations.

This role is one that works across the organization and negotiates up and down to keep a Product Portfolio on track. It is demanding and time consuming, but with a strong Product Management team, it is highly rewarding when thing go right. Conversely, this person can sink a company if they are not successful.

Using Lean Canvas in (Agile) Epics

A novel approach to utilizing Lean Canvas within Epics in an Agile methodology

Most of us in product / engineering organizations within software companies evolved into Agile development life-cycles over the past ten to fifteen years.  Most of us started out pretty straightforward applying the basic Agile Manifesto probably combined with a Scrum foundation.  Of course, many offshoots and variations emerged and even still younger compliments to Agile continue to emerge, such as Lean Canvas, Lean MVP and others.

I’ve been finding reasons to apply Lean Canvas and MVP approaches for the past five years and have had some interesting successes and failures.  This blog post presents one recent success using Lean Canvas, but in what might be a unique and helpful variation for your organization.

At Envysion, Inc., we were exploring the Lean Canvas, er, canvases approach, as well as following advice from the Silicon Valley Product Group. This meant we were filling out canvases for specific product lines or new product feature groups. We found Lean Canvas and Lean MVP are designed for smaller software projects and are ideal for the first generation (MVP) of a product. For a more mature product company (Envysion is a 100-person company with over a hundred enterprise clients and tens-of-thousands of enterprise end-users), the approach can be somewhat lacking.

Then one of our thoughtful and innovative product managers had an interesting idea:  Use the Lean Canvas structure essentially as the “body” of Epics (and/or Initiatives).  Here’s how it worked…


Within our Agile methodology, we adhere to the approach that Themes beget one or more Initiatives which beget one or more Epics beget one or more Stories beget one or more Activities.  There is always more work than we can possibly address within a quarter (our planning extends out six quarters at the moment).  If we apply the Lean Canvas approach to feature groups, we’d be writing a lot of Lean Canvases.  That’s not necessarily a bad thing, really, but combined with the fact we also have to write a lot of Initiatives and Epics, it adds up to a lot of time we don’t have.

When writing Initiatives and Epics, we were following the general approach that you might learn from an Agile coach or through your own experience of writing requirements and Stories and such over the years (As a… , I need… so that). We were consistently providing context and background, a description of what the problem is, how we might want to solve it and what benefit our customers might gain from the result. One of our product managers realized this approach encompassed most of the aspects of a Lean Canvas. In an effort keep our Initiatives/Epics short-and-sweet, we decided to migrate to the Lean Canvas approach, but still provide a consistent structure of information to the reader.


We now simply apply the Lean Canvas structure to every Initiative and Epic.  There are a few slight variations of the Lean Canvas format out there (and no real standard, yet) but the one we adopted looks like this, which each of these bullets representing a section that is no more than one or two sentences or a short bullet list…

  • Problem
  • Existing Alternatives
  • Solution
  • Key Metrics (of successful Solution)
  • Unique Value Proposition (of our Solution)
  • Unfair Advantage (of our Solution)
  • Channels to Market
  • Customer Segments (including Early Adopters identified)
  • Cost Structure / Considerations (which we measure in Points or “Organizational Dollars”)
  • Revenue Model / Potential


The results have been pretty impressive, substantive and immediate:

  • These turns out to be very fast to write, once you get the hang of it.  It takes a little training, which you can find online in a few blogs easily one good resource from is here: LeanCanvas), your product managers will get it quickly.
  • Engineering and marketing seem to love it as well, so much so we’ve seen other organizations start to use the basic canvas template for their own department’s work.
  • It also seems to help the scoping of the child Stories within those Epics quite a lot, which Engineering also loves.
  • The learning curve of new product managers and engineers is shortened, and the transition time is shortened if we move a product manager to a different product.