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 :)

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