Not storytelling as performance. Not storytelling as spin. Storytelling as clarity.

Tony Fadell makes this point clearly in his product thinking. When builders are too technology-led, they talk about the what. They talk about the feature, the model, the architecture, the device, the mechanism. But customers need the why. The why is the story.

That idea has stayed with me because it explains why some products feel obvious once they are explained, while others feel confusing even when the technology is impressive.

A Product Needs to Be Understood

A product does not only need to work. It needs to be understood.

This sounds simple, but it is one of the hardest parts of building. You can create something technically strong and still fail because people do not know what to do with it. They do not know what category to put it in. They do not know what pain it solves. They do not know why it is different from what they already have.

Storytelling gives the customer a frame.

It says: here is the pain you already know, here is why the old way is broken, here is what changed, and here is the new behavior that is now possible.

Without that frame, the customer has to do too much work. And most customers will not do that work for you.

The Story Shapes the Product

The best story is not written after the product is finished. It is discovered while the product is being built.

If you try to tell the story early and it does not work, that is useful signal. Maybe the pain is not sharp enough. Maybe the customer is too broad. Maybe the feature set is scattered. Maybe the product promise is stronger than the product experience. Maybe the workflow does not deliver the emotional relief you are claiming.

This is why storytelling is a product skill, not just a marketing skill.

When you write the story, you are forced to make choices:

• Who is this for?
• What pain matters most?
• What is the before and after?
• What should the customer believe after seeing it?
• What should we avoid saying because it creates the wrong expectation?
• What does the product need to prove in the first five minutes?

Those questions change the roadmap. They change onboarding. They change pricing. They change what you demo. They change what you cut.

The story is not decoration. It is a constraint that helps the product become coherent.

Steve Jobs Practiced the Story Before the Launch

One detail from Fadell’s conversation that I love is the way he describes Steve Jobs practicing the iPhone story repeatedly before the public launch. By the time people saw it on stage, it felt natural. But it felt natural because the story had been honed.

That is an underrated lesson.

Great product storytelling is not a last-minute script. It is the product strategy compressed into a sequence people can feel.

The original iPhone story worked because it created tension before it revealed the answer. It helped people understand the problem with existing phones, the limitation of physical keyboards, the power of software, and the idea of a device that could become many things.

The story made the product legible.

Every product needs some version of that. Maybe not a keynote. Maybe it is a landing page, a sales demo, an onboarding flow, a founder memo, a product video, or the first conversation with a customer. But somewhere, the product needs a story that makes the value click.

AI Makes Storytelling More Important

AI has made storytelling more important, not less.

Because now it is easy to build things that look magical for thirty seconds. A demo can summarize, generate, chat, classify, automate, or recommend. But after the initial magic, the customer still asks the same questions:

• What is this for?
• Can I trust it?
• Where does it fit into my workflow?
• What does it replace?
• What happens when it is wrong?
• Why should I change my behavior?

If you cannot answer those questions clearly, the AI becomes a novelty instead of a product.

In AI, the story also has to set expectations. If the product is probabilistic, say so through the experience. If the human remains responsible, design for that. If the system saves time but still needs review, do not market it as full automation. A good story does not just create excitement. It creates the right mental model.

That is especially important in healthcare. A clinical AI product cannot survive on “look what the model can do.” It has to tell a more grounded story: less administrative burden, more presence with the patient, better documentation workflows, human review, trust, privacy, and time back.

The story has to be ambitious and honest.

Storytelling Aligns the Team

Storytelling is also how teams align.

A clear product story helps engineering understand what details matter. It helps design know what emotion the experience should create. It helps marketing know what promise to make. It helps sales know which customer to pursue. It helps support know what confusion to expect. It helps leadership understand what tradeoffs are being made.

Without a story, every function fills in the gaps differently.

Engineering may think the technical breakthrough is the product. Sales may sell whatever closes the deal. Marketing may choose language that sounds good but attracts the wrong customer. Design may polish a flow that does not lead to the real value moment. Product may end up managing a collection of disconnected requests.

A story gives everyone the same north star.

Not a vague mission statement. A concrete narrative of customer pain, product promise, and why now.

The Best Stories Are Earned

There is a dangerous version of storytelling that becomes exaggeration. That is not what I mean.

The best product stories are earned by the product. They do not hide weaknesses. They sharpen truth. They name a real pain and show a credible path to relief.

That is why Fadell’s broader product philosophy matters here. Start with pain. Use technology in service of the customer. Sweat the details that matter. Make opinion-based decisions with an informed gut. Iterate until the product becomes strong enough to carry the promise.

The story and the product have to meet each other.

If the story is bigger than the product, customers feel misled.

If the product is bigger than the story, customers may never understand why it matters.

The craft is bringing them together.

A Simple Test

A useful test for any product is this:

Can you explain it in a way that makes the right customer feel seen?

Not impressed. Seen.

The customer should feel like you understand the pain they have been carrying. They should understand why the old way was insufficient. They should see what changed. They should believe the product was built for their world, not just for a demo.

That is storytelling.

And in product management, storytelling is not extra. It is how the product becomes real in the customer’s mind before it becomes real in their workflow.

Storytelling Is a Product Skill was originally published in The Product Playbook on Medium, where people are continuing the conversation by highlighting and responding to this story.

You can have a thought in the morning and touch a working version by lunch. You can ask for a prototype, run it, see what feels wrong, change the prompt, edit the code, test again, and keep going. The distance between “I wish this existed” and “here is a rough version” is collapsing.

That is genuinely exciting. It lets more people build. It lets product people, designers, founders, clinicians, operators, and curious people get closer to the work without waiting for a perfect handoff.

But it also creates a new risk.

When the machine can produce more output than we can carefully inspect, it becomes easy to confuse building with approving. The tool gives us something plausible. We accept it or reject it. The button works. The page renders. The demo passes.

But were we actually inside the work?

That question matters because the point of building is not only to produce an artifact. Building is one of the ways we learn to see clearly.

The Loop Is Where Judgment Forms

I used to think of software development mostly as execution. You understand the problem, define the product, design the experience, write the code, ship the feature.

That is still true at one level, but it misses the part where judgment actually forms.

Most good ideas do not arrive fully shaped. They become clear when they meet reality. You build a version and realize the workflow is too heavy. You write the copy and realize the promise is wrong. You design the screen and realize the hierarchy is unclear. You run the model and realize the output is technically correct but not useful.

That small moment of noticing is everything.

The thing exists now, so it can push back. You are no longer arguing with an abstract idea. You are responding to something concrete. This is where taste develops. This is where product judgment gets sharper. This is where the work teaches you what it wants to become.

AI makes that loop faster. That is the good part. But if AI hides too much of the loop, it can also make us weaker.

If the system disappears into a black box and returns an answer, we may get output without learning. We may get working software without understanding why it works. We may approve surfaces without developing the judgment that would let us make better surfaces next time.

Output Is Not the Same as a Loop

There is a difference between getting an output and being inside the loop.

Output says: here is the answer.

The loop says: look at this, question it, shape it, make it better.

That distinction feels small, but it changes the whole relationship between a person and a tool. A black-box AI system optimizes for output. It wants to satisfy the request and move on. That can be useful for many tasks. I do not need to inspect every summarization or every formatting pass.

But creative and product work is different. The value is not only in receiving an answer. The value is in seeing enough of the process to notice what the answer means.

Does this workflow create trust? Does this interface make the user feel capable or confused? Does this automation remove pain or hide responsibility? Does the product feel like someone cared?

You only see those things when the loop stays visible.

This is why I think the best AI tools will not just generate. They will reveal. They will show their plan, expose the changes, let you inspect the reasoning, let you pause, steer, take over, and go deeper when the detail matters.

Not because every person wants to control every step. That would be exhausting. But because the option to go deeper is part of agency.

The Interface Teaches a Posture

Every tool teaches a posture.

Some tools teach you to explore. Some teach you to wait. Some teach you to fiddle with details. Some teach you to outsource your thinking.

This is why AI product design matters so much. The interface is not neutral. If the system turns the user into someone who makes wishes and approves finished artifacts, the user slowly becomes less of a builder. If the system lets the user see, shape, question, and intervene, the user can become more capable over time.

That is the version of AI I care about.

Not AI as a vending machine for finished work. AI as a way to bring more people into the loop.

A designer should be able to get close to implementation. A product person should be able to make a working prototype. A clinician should be able to shape a workflow without becoming a software engineer. An engineer should be able to explore an architecture with more speed and more context.

The tool should scale with the user. Simple on the surface, deeper when needed.

That depth matters because the details are often where the truth lives. One weird edge case can tell you the product model is wrong. One sentence of copy can reveal that the promise is too vague. One command failing can expose a mistaken assumption about the system.

If the interface hides all of that, the user may move faster, but they are also learning less.

Speed Makes Taste More Important

The obvious story about AI is that it makes creation cheaper.

That is true. But when creation becomes cheaper, taste becomes more important, not less.

The world does not need infinite software that technically works and emotionally means nothing. It does not need endless dashboards, agents, automations, chat boxes, and workflows that fill space without solving real pain.

The danger is not that more people can build. That part is wonderful.

The danger is that we build more things without caring more.

This is especially obvious in product work. AI can generate ten versions of a feature, but it cannot tell you which version deserves to exist. It can write the code, but it cannot own the customer promise. It can summarize feedback, but it cannot decide what kind of company you are becoming by listening to one customer and ignoring another.

Those are human judgments.

The scarce skill is not typing a better prompt. The scarce skill is knowing what to ask for, what to keep, what to refuse, and where to slow down.

When output is abundant, refusal becomes a craft.

Craft Moves Upstream and Downstream

I do not think AI removes craft. I think it moves craft.

When execution is expensive, craft lives heavily inside execution. The line of code. The layout. The transition. The exact words in the empty state. The careful QA pass.

Those things still matter. But as AI handles more execution, craft also moves upstream into judgment and downstream into responsibility.

Upstream, craft is deciding what should exist. What is the real customer pain? What should the system never do? What should remain manual? What should be legible? Where does the user need control? Where does automation create confidence, and where does it create risk?

Downstream, craft is owning what you release. Who does this help? What behavior does it reward? What happens when it is wrong? Does it make people more capable, or more dependent? Does it give time back, or does it just create more things to manage?

This matters a lot in healthcare. An AI clinical workflow cannot just be impressive. It has to be reviewable. It has to respect privacy. It has to show uncertainty. It has to fit into the reality of clinician time, patient trust, documentation burden, and liability.

The model may generate the note, but the product has to preserve responsibility.

The Point Is Agency

The best version of AI does not make humans disappear from the work. It makes more people feel capable of entering the work.

That is the difference I keep coming back to.

I do not want tools that make us passive approvers of plausible output. I want tools that shorten the distance between imagination and reality while keeping the loop visible enough for us to learn from it.

Because the magic is not only that something can be generated. The magic is the moment when something that lived only in your head becomes real enough to touch, question, improve, and share with someone else.

That is why building feels meaningful.

You notice a gap. You make a mark. The world answers. You adjust. The thing becomes clearer. And somewhere along the way, the idea stops being a thought and becomes a place where other people can stand.

AI should make that feeling more available to more people.

It should help us move faster, but also see more clearly. It should make the work more accessible, but not less human. It should give us leverage without taking away authorship.

The future I want is not software building itself while people watch.

It is more people being able to say: I felt this should exist, and now I can make it real.

Keep the Loop Visible was originally published in The Product Playbook on Medium, where people are continuing the conversation by highlighting and responding to this story.

It’s an ongoing process and it is advisable for PM teams to have at least one new feature in discovery at any given time, roughly one per quarter.
I have two more articles on Discovery:

https://productology.medium.com/product-discovery-in-details-4c11f3579519

1. Assess the Problem space. Think it

1.1. Comprehend the situation (define the goal, product outcome, not an output)
How? By doing secondary research

• external
  - Space: search reddit forums. Understand how the features are currently used
  - Competitors
• own: search through feedback database (Monzo)

1.2. Identify the user. Then mark the user journey (all steps from start to the end including how they feel at each point). How: by talking to them.

ProTip: use 5WHY technique. Ask why 5 times in order to reach the root of the actual problem.

Schedule interviews. Use the data from research when talking to users.

1.3. Build a stakeholder map (who needs to be involved in the decision making process along the project).

1.4. Define the Problem
Look at intensity and frequency. What type?
- Friction: a barrier, smth missing
- Other type: ambiguous
Worth solving this problem?

2. Solution Space

WHAT! from a user perspective. Not HOW yet.
2.1. Come up with Solution hypotheses (How-Might-We)
Suss it out / determine how the solution will work on a high level in Figma. Prepare a prototype, pilot or a proof-of-concept (simulate the real world set up).

2.2. Data collection to validate the solution hypotheses

• Get quantitative data
  Work with Analyst to help you to gather the data to validate the solution hypotheses
  - Example: if you NPS after a call and ask if the connection was an issue
• Get qualitative data
  Work with UX research team and run studies. Bring CS and see how much complaints.
  Use prepared prototype simulating the real world set up

=> test the Solution hypotheses

2.3. Testing the Solution for the following risks:
- value prop risk
- usability / design
+ check feasibility (below)
+ check the business viability

Why?
1. To account for these risks and mitigate them -> plan ahead of the time or event
3. To show you foresee it and use to address questions (create a slack channel and add the team, stakeholders)
4. Part of the PRD

2.3.1. Business viability risk
What are the constraints, ex: regulatory. How would that affect the entry, pricing of the product, etc?

Example: if it’s required to store personal info, compliance will be required.

How to assess?
- talk to legal team
- consultants

2.3.2. Value prop risk
How to assess?
By interacting with the buying persona. Read more on User research here.

ProTip: In b2b it’s often that buying persona is different to a user persona

Test with 5 users (stop after 6 users if no new findings). You could use https://dovetailapp.com and bring stakeholders to feedback on findings.

ProTip: How to bring the team / stakeholders on board?
- record the sessions with users
- get 1 min snippet
- share with the team: UX, engineer..

Why?
- increased motivation
- to understand the priority
- to get ideas early on -> save you time..

Things to take into account:

Key metrics
Depends on the stage.
- At launch: is this working? People able to use these features?
- Later: engagement around the feature. NPS
- After: retention.

How this affects the North star?
If all good, then put these all into PRD (do this all the time even if feature request from the CEO) and move to stage 5.

ProTip: until this stage only go to developers when there is something doesn’t exist.

Start drafting:

• 1-pager / 6-pager -> PRD
  Synthesize all the findings and concisely write it into business case
  - Competition (pros and cons)
  - Trends (3D)
• Think of a prototype (how do I imagine this working)

2.3.3. Usability risk
Whether the user understand how to access the value we’re proposing.
It’s done by testing the prototype or a mockup (ask the designer to create one). It’s an incremental process.

Prototype 1 -> Prototype 2 -> which then turns to MVP (a value unit)
Tool to use: https://www.userlytics.com

2.3.4.Feasibility risk assessment evaluates
- engineering capability
- support team capability

1st meeting with the Engineering Lead (EL).
High level feedback on PRD draft.
Designers / Execs / Engineers to comment on the doc -> Engineers will write a doc describing the build (tech solution) -> Then we list epics together (in-person)

ProTip: involve them early on, share links. If they see the impact is high, they will prioritise this.

Outcome options:
- too expensive to build
- there are more impactful things to build (RICE or Kano model (delightful) if difficult to estimate or combination of both methods). If that’s the case then bring in to the next refinement when you complete the most impact
- if positive, discuss capacity (Is this backend? Is this front-end? Rough timeline?)

3. Build it

ProTip: PM’s goal is to ship something to learn and get feedback.
In order to change stories ahead of the time
2nd: Make work as efficient as possible by removing barriers.

3.1. Refinement.
2nd meeting with LE. Deep-dive.
LE - Functional and non-functional descriptions
PM - Efforts required
Goal: feedbacks and clarifications until approved.
Read detailed refinement process here.

3.2. Prioritisation
If same score for various epics — go with one which brings the outcome (something to show). Engineers write tickets (genkins methods).
Read detailed prioritisation process here.

ProTip: be upfront with what’s Must have and Nice have things.

3.3. Sprint Planning
Depending on the stage you may need to start with onboarding the team, setting up the Scrum: milestones and prioritisation.
Read detailed sprint planning process here.

Gage the progress of the team by weekly meet ups. Also daily stand-ups (3 ppl: PM, Leads). Stand-ups there to talk about roadblocks!

Add monthly check-points

4. Ship it

Roll out the feature with AB test and see the metrics:
- time-spent
- successful number of completed sessions (incremental value)
Data science team will tell for how long to run / how many users to avoid being in false positive.

Why AB test?
Determine incrementality on baseline, treatment (noise vs added value)
To protect bad user experience (accidentally crash the site)

This is possible if below available. To get testing setup:
1. Feature flag available i.e. ability to turn on and off the features -> define the spec to engineering team
2. Analytics instrumentation. Are the metrics being fired on per user features (data analysed)

ProTip: this is not permanent. Epics on the backlog are only bets! It’s on a roadmap only if the items are vetted! Lots of features can be only hypotheses.

5. Tweak it

Ideally dashboarding tool will help to monitor the performance. Use Mixpanel / Amplitude

How a new feature can fail:
- nobody uses it (don’t know how or what -> extra backlog)
- some traction but behaviours don’t change, still uses zoom.

What to do if fails?
Calculate how much it costs to maintain —> put it in maintain mode.

Credit: Teresa Alvarez, Sumanyu Sharma, Daniel Eugénio

Did you find this information helpful? If so, click the “follow” button to receive notifications when I write my next article on project management. If you would like to show your appreciation or support my future work, you can buy me a coffee at the following link: https://ko-fi.com/ayuby

→ Follow Product Playbook on X: https://x.com/intent/user?screen_name=jakebarlo

Product discovery process (brief) was originally published in The Product Playbook on Medium, where people are continuing the conversation by highlighting and responding to this story.

Why is vision important?

Vision is your aspiration, your energy and driver. Vision is what push you to accomplish what you wanted to be. It’s your dream! Dream big and make it happen! Just like a company who has big vision about how their company wanted to be embraced in the industry and their customer, a product also need a vision that allows a product to grow and how a product will be perceived by their customer. Your product vision should give a picture about what your customer could expect when they are using your products because they’re your muse!

Therefore, there are several things you should consider when creating your product vision:

1. Include your customer/user in it

Remember what I said before, your customer is your muse. Therefore, you need to be very considerate about what your customer need and their expectation, but don’t forget about your company/business need, they need money too. So, your product vision should serve both the business and the customer.

2. It should be a stretch, but attainable

Your product vision is your dream about how your product should be like, so you can make your product vision as broad as possible. However, remember that it should be achievable, it should be realistic, and get deep into your product, NOT something like “the best platform”. Try to elaborate it such as “the most reliable”, “the most go-to platform for …”, “the all in one platform”

Be creative guys!

3. Show distinction with the other product that already existed

Do you familiar with this “Most of nowadays big company is not a first-comer in the industry”. Just like Facebook, their service is mostly the same as MySpace or Friendster. But Facebook is the winner (it exists until now). So, your product needs to deliver a distinction with the other, even though maybe you have the same business model/similar service with the other business, you can diversify your customer segment or serve unique values compare to the others which already exists.

4. Look several years ahead!

The market is always constantly changing, therefore your product vision should be valid for several years in the future, it shouldn’t be easy to change. So, give it some room for improvement of your products.

Let’s breakdown our favorite platform’s vision: Yes, Medium!

Medium is a platform where you can publish your writing worldwide and consume any writing content globally regardless their background, whether from an amateur or a professional copywriter/publishing company.

Therefore, the company vision can be arranged into something like this :

“Create a platform where readers find dynamic thinking, and where expert and undiscovered voices can share their writing on any topic.”

Or in high-level of product, you can say basically

“Create a simple blogging experience for anyone!”

Breaking down one of their feature, which is also a form of product, take a sample of

*Your feed recommendations to read

This feature provides you with a lot of recommendation of articles for you to read, based on the topic you chose when creating an account and based on your history of reading/the list of reading you created/the articles you like/search for.

Therefore, the ‘feeds’ product vision can be arranged into something like this:

“Provide the most suitable reading recommendation for the readers based on their persona”

Okay, now that we’ve been discussed the product vision, I want to share with you about product strategy.

What is product strategy?

Product strategy in a nutshell is the “how would you accomplish your product vision?”

Obviously, after you create a vision about how your product should be, after you dream about your product, you also wanted to know how you would make it come true. This is where product strategy is needed, product strategy is the step-by-step to create your product, you can say that the product strategy is the milestones you need to prepare before your product can be launched into the market.

The product strategy helps you decide which problem you need to focus on, basically if you wanted to create an e-commerce, take a sample. You need to collect the seller first, you need to create a platform and the system, which consist of designing, creating the customer journey, make a customer segment, also, you need to partner up with payment provider which enables the customer to pay from any payment method, etc. Because there are many things to work, you need to prioritize which one you should be focused on first, therefore creating a milestone will help you to organize your project. You can read more about product strategy framework in here.

Now, in this section I want to brainstorm with you, well you can leave a comment below about my opinion here.

In my opinion, producing a movie should also consider about vision and strategy, just like a product. Well, movie also a form of product, right?

Before creating a movie or a storyline, you need to deep dive about your customer segment, then from there you can start creating your characters, personality, settings, and plot. Who will you reach as your audience? What’s their main interest/what makes them engage? You need to have a theme of your movie and what you want to deliver from the movie (this is your vision). Then, from there you can conduct your research about your audience, create characters and personality based on the themes and message you want to deliver along the story also should be relevant with nowadays settings, create the plot and settings that will engage with your audience and maybe sprinkle some plot twist on the way as surprise element, so it will keep entertain your audience.

This close our discussion today, if you like what I write here, please let me know and leave some claps/comment. I will keep writing about product management along my studies and probably will doing it every week. Chiao!

How to write a product vision statement | Productboard

Welcome to Medium. Bring Your Stories and Ideas | by Ev Williams | Medium

→ Follow Product Playbook on X: https://x.com/intent/user?screen_name=jakebarlo

Product Vision & Strategy in a Nutshell was originally published in The Product Playbook on Medium, where people are continuing the conversation by highlighting and responding to this story.

You want to ensure your product doesn’t suck

Have you ever visited a website and you were left wondering whether it was built by a chaotic bat; or downloaded an app you were excited about but soon after aborted mission because, “who built this thing and what were they thinking?”

No?

Okay, at the very least you have encountered a situation where an app you like or need was inconvenient in specific ways. Either it takes forever to send an OTP, or a button hides a key component you want to use, or for the life of you, you cannot remember where you need to click to do a specific key task because its hidden under several vague menus.

Such scenarios are key indicators of ineffecient or insufficient user testing exercises; where the product or QA team failed to catch bugs or ask the right questions to test users- if at all they tested with actual users.

Alpha and Beta tests are part of the user acceptance testing (UAT) process. UAT is designed to help the product team investigate whether the software developed meets business and end user needs and works as anticipated.

User acceptance testing is important because:

• It helps in the detection of bugs so they’re quickly fixed before they annoy mass users.
• It’s part of the quality assurance process that ensures you sort out any issues that could prevent your app from being blocked by app stores.
• Usability testing that ensures the app or website works in predictable and similar ways regardless of the device being used to access it.
• It helps you test the performance of your software when it’s being accessed by multiple people; things like loading speed, errors and seamlessness are critical to check.
• It helps in spreading product awareness since it can be used as a marketing strategy with your targeted end users. A well organized test process can help you acquire and retain your first group of real users.

There are a few fundamental differences between Alpha and Beta tests. In this article, we’ll focus on how to plan and execute beta testing like the boss you are.

But first;

Differences between Alpha and Beta testing:

Alpha Tests

1. ​Usually performed by internal employees

2. Often perfomed in an internal testing environment (deveoper’s site)

3. Minimal or no focus on security and reliability

4. Critical issues are directly fixed and addressed by developers.

5. Ensures the quality of the product before moving to beta testing

Beta Tests

1. Usually performed by end users who are not part of the company/org.

2. Performed in a real-time environment that’s available to the public

3. Testing is focused on reliability, security, seamlessness and robustness

4. Also focuses on product quality, but with user’s feedback to ensure readiness for mass real-time users.

5. Feedback is collected and can be addressed immediately or on a rolling basis based on urgency and product roadmap.

Three Beta testing tools you can leverage:

1. TestFlight: You can invite up to 10,000 testers using just their email address or by sharing a public link. Testers can download it from the AppStore. Up to 100 apps can be tested at a time. TestFlight supports apps for iOS, iPadOS, macOS, tvOS, watchOS, and iMessage.
2. Firebase Crashlytics: This is a real time crash reporting tool, helps you prioritize and fix your most pervasive crashes based on the impact on real users. Crashlytics also easily integrates into your Android, iOS, macOS, tvOS, and watchOS apps.
3. TestFairy: Works on both iOs and Android and allows users to report bugs by shaking their device or just clicking on a button and sketching on the screen. TestFairy includes an enterprise-grade app distribution platform for iOS and Android that is highly configurable, tightly secured and can sync with your corporate Single Sign-on.

How to map out your beta-testing roadmap:

Stage 1: Getting Launch Ready

1. Key Features Developed: There needs to be something to be tested. And you want the critical features ready to be brought to the test group.
2. Acceptance criteria well defined: ACs guide the testers to measure whether the feature meets the specified expectation. Well defined criteria can be answered using a yes or a no.
3. Software/App Pushed to Test Environment: The initial test environment for Alpha testers is usually a sandbox or a developer’s site. The App/Sotware should be available in that environment to allow for testing.
4. Alpha testers added to sandbox/test environment: Alpha testing is done in a closed environment with limited access. The testers (usually internal team members) have to be added into the environment so they can access the app/software for testing.
5. Internal Alpha-testing of App completed: Internal alpha testers mark yes or no on the acceptance criteria of specific features to indicate whether they work as stipulated or not.
6. App pushed to production: Once the alpha test is done and changes made, the developers push the app/software to production (ie AppStore/Playstore) or soft-launch the website so it can be accessed by the public/beta testers.

Stage 2: Beta-Planning

1. ​Create beta- test SMART goals and tasks: Specify the tasks you want to test through the beta-test expercise, and the goals you want to achieve with the exercise. Some key goal-setting questions could include: What do you want from this beta program? Will you be engaging these users on a weekly, monthly, or quarterly basis? How will you be engaging them? Will it be simply for new features or innovation and new product releases? How often will you require them to give feedback?
2. Finalise on the testing strategy to be used: This could include specifying whether it’s virtual, in-person or both; how long the testing period will last, what rewards (if any) will be offered to the testers, and where the testers will be found.
3. Assign team responsibility in the testing process: Ensure every stakeholder knows their role and the associated deadlines; this includes any review or approval processes (such as budgetary approvals)
4. Narrow down specific dates and deadlines: You want to be have a limited window so that testers stay engaged and prioritize the process.
5. Decide on any beta-testing tools needed, where appropriate: ​Test your new software on multiple platforms and beta-testing tools. Depending on the software, this could involve testing it on both MAC and PC computers, both iOS and Android mobile device, and Chrome, Edge, and Safari internet browsers. The software could behave differently across different platforms. Different testing tools/platforms allow you to test for specific things, so choose approriately.
6. Create a communications plan/strategy for the beta-testing exercise: Timely, clear and targeted cross-functional and external communication makes for a seamless testing exercise

Stage 3: Legalities and Shortlisting

1. Prepare an NDA and Participation Agreement for testers to sign: You don’t want your idea stolen before it makes it to the market; or to get sued because you processed a tester’s personal information without express permission.
2. Create ideal test-user persona: You want your target market to make a significant part of your test user group, so you know that you’re building something YOUR users want.
3. Coordinate with internal teams to help shortlist potential test users: Customer success, social media team and sales team can help curate targeted, precise list of users who fit your test group persona.
4. Reach out to communities where test users are likley to be: You want to let people know you’re ready for launch and keep them excited to receive a solution to a problem they’re facing. Excellent marketing
5. Settle on dates and locations or virtual rooms for the beta-testing: You want to communicate, well in advance to your test users the logistics around the exercise.

Stage 4: Beta-testing

1. Specify internal team members to beta-test and their locations (if in-person): Relevant team members need to own specific parts of the testing exercise; and team can map out availability.
2. Organize logistics for team members (digital or physical): Prior preperation helps everyone feel in control and prepared to do their best work.
3. Organize logistics for testers, if necessary (internet, location, transportation and meals; if in-person): Users should feel that you care about their convenience.
4. Communicate relevant information with beta-testers consistently: You want as many shortlisted participants as possible to show up for the testing exercise.
5. Conduct the testing over the specified range of dates: Time to know whether you’ve built something worth having.

Stage 5: Beta Feedback

1. Bug reports: Fix them before they annoy and frustrate everyone else.
2. Submit Feature requests or improvements: You know what your users want more of; add it to your backlog and you’ll refine it later.
3. Journal/Note-take: Take real-time notes of your observations and insights you gather as you carry out your exercise
4. Evaluate Feedback: Ensure you come up with the correct POV when you look at the feedback in toto.
5. Map required changes where necessary: ​Groom the backlog of feedback into now, next and never columns of changes to be made.

Stage 6: To the Moon!

Beta testing as a beginner:

As a PM, you’ll encounter your very first user testing exercise. Or, an opportunity to stop limping through the process and do it well.

I’ve created a user-testing playbook that helped me facilitate cross-country testing exercises, leading to my promotion just 8 months into my first product role. This playbook is now available on Gumroad and is filled with Notion templates that will help you plan the logistics, communicate with users effectively, and record their feedback.

With this playbook which includes other resources that are helpful for a new PM, you can take the guesswork out of user testing and ensure that your products are designed to meet the needs of your users. Don’t miss out on this opportunity to take your product strategy to the next level.

You can get the Testing Textbook here

My name is Cindy aka Product Queen. I’m a non-coder of a PM who got promoted 8 months into my first ever official product role because of my capacity to create processes from scratch and collaborate like a boss.

Find my portfolio here where I also take product newbies through specific ways to kick ass as a new PM.

You can check out the PQ Kickstart Kit for brand new PMs here.

→ Follow Product Playbook on X: https://x.com/intent/user?screen_name=jakebarlo

Road to Release: Your step-by-step guide to beta-testing in 2023 was originally published in The Product Playbook on Medium, where people are continuing the conversation by highlighting and responding to this story.

The №1 challenge you have to navigate during user interviews is people’s inability (or unwillingness) to disappoint you. They will want to first assume THEY are the problem, that THEY are the ones clicking on the wrong button, or misunderstanding something, before the realisation dawns on them that what you’ve brought to them is umm… full of friction.

Most panelists (i.e users who will be testing your product) will want to inundate you with reasons why they like what you’re showing them and how it’s ‘such a good idea’. Testers tend to be a bunch of ‘mums’ who think every idea is a good idea, but you’ve got to take them through ‘The Mum Test’. It is YOUR job to fight the unmerited glee to settle for untested positive feedback.

Before I get to the list of questions below, there are a couple of things that can help you tease out what your panelists true opinions are:

1. If it’s prototype testing, let them know that YOU did not design the thing, you hired a ‘guy’ or someone else in a different team did it and you want to find out if they’re doing a good job or not and that you hope your panelist can help you assess that. You want to remove the fear of offending you from your panelist.
2. If it’s an in-person test, reward anyone who finds a bug or a friction point with sweets (surprisingly, adults like these) or a dollar or a badge for the top bug-finder; anything that incentivizes your panelists to notice things that are not quite right. You want to normalise the experience of delivering bad news that your product kind of sucks. That’s the only way you’ll know what to fix.
3. You make it explicit at the beginning of the session that the goal is to find out what ‘issues’ exist so you can solve it for them; the more direct and honest they are, the more helpful their feedback will be. Everyone likes to be helpful.

The questions you ask will depend on what kind of user interview you’re doing and obviously the product you’re testing. Usually, there’s 4 testing exercises you do before launch, you can read more about them here.

Questions you might ask during a discovery exercise:

• What are your current pain points or challenges in relation to the product or service category we are offering?
• What do you like/dislike about similar products or services currently on the market?
• What features or functionality are most important to you in a product or service like ours?
• What would you be willing to pay for our product or service?
• How often do you envision using our product or service?
• What are your top priorities when considering a purchase in this category?
• What would make you choose our product or service over competitors?
• Can you think of any potential drawbacks or drawbacks of our product or service?
• Are there any additional features or functionality you would like to see in our product or service?
• How likely are you to recommend our product or service to friends or colleagues?

My favourite questions to ask during prototype testing:

• Bad news only, what don’t you like about product/feature/functionality/process/look?
• What has been the most confusing part of this experience for you?
• What would you add or remove from this design or process?
• What do you think we might be forgetting?
• What do you understand by X on this page?
• What would prevent you from enjoying this product?
• If you could add one feature to the product, what would it be?
• How likely are you to recommend this product to a friend or colleague?

Questions during performance testing and beta launch:

• Are you able to create an account? Did the OTP arrive on time?
• Are all images loading correctly? Are buttons working?
• If you put your phone on landscape mode, are you still able to scroll up and down?
• How’s the loading speed on your device?
• Are you able to navigate through key tasks with relative ease?
• How seamless is it for you to navigate through the pages as you need to?
• Can you easily find (a button, a feature, a page) that you’re looking for?

When facilitating user interviews as part of focus groups, user testing or just a good old ‘talk-to-your-users’ session, you might need to learn how to ask questions like a therapist would. You want to capture the emotions and the mental journey your user is going through when looking to answer your questions or test your product. These are great follow-up questions when a user responds a specific way or chooses a specific button over another.

Examples of things a Therapist would Say:

1. Something happens that seems to surprise them. For instance, they click on a link and say “Oh” or “Hmmm” when the new page appears. You could ask: “Is that what you expected to happen?”

2. The participant makes a comment, and you’re not sure what triggered it. You could ask: “Was there something in particular that made you think that?”

3. The participant suggests concern that he’s not giving you what you need.“No, this is very helpful.” “This is exactly what we need.”

You can read more about it Things a Therapist would Say here.

User testing as a beginner:

As a PM, you’ll encounter your very first user testing exercise. Or, an opportunity to stop limping through the process and do it well.

I’ve created a user-testing playbook that helped me facilitate cross-country testing exercises, leading to my promotion just 8 months into my first product role. This playbook is now available on Gumroad and is filled with Notion templates that will help you plan the logistics, communicate with users effectively, and record their feedback.

With this playbook which includes other resources that are helpful for a new PM, you can take the guesswork out of user testing and ensure that your products are designed to meet the needs of your users. Don’t miss out on this opportunity to take your product strategy to the next level.

You can get the Testing Textbook here.

My name is Cindy aka Product Queen. I’m a non-coder of a PM who got promoted 8 months into my first ever official product role because of my capacity to create processes from scratch and collaborate like a boss.

Find my portfolio here where I also take product newbies through specific ways to kick ass as a new PM.

You can check out the PQ Kickstart Kit for brand new PMs here.

→ Follow Product Playbook on X: https://x.com/intent/user?screen_name=jakebarlo

Sample questions to ask during user interviews as product manager was originally published in The Product Playbook on Medium, where people are continuing the conversation by highlighting and responding to this story.

User testing involves gathering feedback from users on a product or service before its release to the market. The insights gathered from this process can help businesses make necessary improvements and adjustments to enhance the user experience.

There are many different types of product testing that can be beneficial before launching a new product.

Here are four common types of product testing that can help ensure a successful launch:

1. Discovery research
2. Prototype testing
3. Performance testing
4. User experience testing

1) Discovery: Let your users tell you what they want

This type of testing involves surveying potential customers to gauge their interest in and willingness to purchase the product. This can help identify potential customer segments and their needs, as well as any potential barriers to purchase.

Some of the ways you can pull this off is through:

• Focus group sessions with specific segments of your users,
• Going through user feedback to find out what their pain-points are,
• Looking at what the competitive market is offering and how you can leverage your areas of strength to provide better service to your users.

Unless you’re looking to build the first car as an upgrade from using horses, your users will tell you want they want; perhaps not as eloquently, but vocally all the same. Read this if you’d like to learn more about how to approach discovery as a PM.

2) Prototype testing

Before launching the final product, it is important to create a prototype and test it with a small group of customers or potential customers. This can help identify any design or functionality issues, and allow for necessary adjustments to be made.

Prototype testing can be a bit of a hustle. For software products, you’re technically asking a bunch of your users to sit through a simulation of what the final product will look like and then answer a bunch of qualitative questions. The hardest part about this process isn’t about the exercise itself, it’s getting users in the room in the first place.

You will need to properly incentivise them (whatever that looks like), get them to show up hopefully excited and engaged, share with them a link to the prototype which sometimes is just hosted on Figma preview and tease out honest responses from them. People will NOT want to ‘offend’ you so they will try their best to dilly-dally around something they think is frankly s*it.

You can do this online, in-person, through a WhatsApp call or phone call; whatever gets you user feedback.

Don’t panic, I’ve learnt how to do this swimmingly well and I created an end-to-end playbook you might appreciate. You can find it here.

3) Performance testing

You want to know that your product works as intended on the devices and within the context your users will typically use it in. This is why we have alpha testing exercises.

If a majority of your users are in a location with minimal internet connection, or use devices with limited storage or operating capacity, you want to make sure that they can seamlessly use what you’ve built for them or they will get frustrated and move on to their own devices (*wink wink, get the pun?)

This type of testing involves putting the product through various scenarios and conditions to ensure it performs as intended and meets all relevant quality and safety standards. This can include testing for durability, reliability, and other key performance metrics.

Sometimes, performance testing also includes compatibility testing. Compatibility testing ensures that the product is compatible with a range of different devices, operating systems, and other software. This can help ensure that the product works seamlessly across different environments and platforms.

Again, here’s a playbook that you can use when planning out your testing exercises.

4) User experience testing after you launch your product.

You will typically do this with a wider group after doing the performance testing above through beta testing programs. This is when it’ll be in the hands of your actual users, randomised and segmented.

This type of testing evaluates the performance of the product under different conditions, such as different workloads or user scenarios. This can help identify any performance bottlenecks or issues and ensure that the product can handle expected levels of usage.

User experience testing also involves observing how users interact with the product, and collecting feedback on their experience. This can help identify any usability issues or user frustration, and allow for necessary improvements to be made. It involves evaluating how easy it is for users to navigate the product and complete common tasks. This can help identify any usability issues and make improvements before the product is launched.

User testing as a beginner:

As a PM, you’ll encounter your very first user testing exercise. Or, an opportunity to stop limping through the process and do it well.

I’ve created a user-testing playbook that helped me facilitate cross-country testing exercises, leading to my promotion just 8 months into my first product role. This playbook is now available on Gumroad and is filled with Notion templates that will help you plan the logistics, communicate with users effectively, and record their feedback.

With this playbook which includes other resources that are helpful for a new PM, you can take the guesswork out of user testing and ensure that your products are designed to meet the needs of your users. Don’t miss out on this opportunity to take your product strategy to the next level.

You can get the Testing Textbook here.

My name is Cindy aka Product Queen. I’m a non-coder of a PM who got promoted 8 months into my first ever official product role because of my capacity to create processes from scratch and collaborate like a boss.

Find my portfolio here where I also take product newbies through specific ways to kick ass as a new PM.

You can check out the PQ Kickstart Kit for brand new PMs here.

→ Follow Product Playbook on X: https://x.com/intent/user?screen_name=jakebarlo

Four types of product testing you should do before launch was originally published in The Product Playbook on Medium, where people are continuing the conversation by highlighting and responding to this story.

A sharp knife doesn’t make a great chef, but it sure turns cooking into an absolute delight.

As a product manager, having the right tools at your disposal will determine whether you operate blind as a bat or brilliant as Einstein. For non-technical product managers, just because you cannot code doesn’t mean you cannot leverage technical tools that help you develop and share new insights with devs, designers and leadership.

Good news is, it is not rocket science and you do not need to be the world’s no 1 expert at these. All you need to do is know what they do, why you need them and how to use them to achieve your specific goals.

Let’s jump right in:

Tech tool #1 — Wireframing, Prototyping and Design tools.

This could be Figma, Balsamic or Mockflow.

It could also be a blank sheet of paper where you can map out screen flows, draw out content architecture and essentially take yourself through the journey your end user would follow if you developed the feature or product.

Knowing how to put your ideas to paper helps you communicate your ideas to the engineers and even designers. Having your designs or ideas look pretty is a nice-to-have; not completely essential. But it will give you the opportunity to think and communicate like the powerful product manager you are. A good communicator is a good leader.

Tech tool #2- Roadmapping tools

These could be ClickUp, Roadmunk, ProductPlan or ProductBoard.

Even good, old Excel could work here.

Roadmapping helps you visualise the journey your product will take from Point A to Point B. This usually includes new features introduced, new markets you’ll enter into and sometimes even what you’ll be discontinuing because of a changing business or regulatory landscape.

Roadmaps are more of a communication tool than a strategy tool. They help you tell different stakeholders what to anticipate over the coming months. Ideally, roadmaps shouldn’t stretch more than 4 quarters or they risk becoming redundant and less agile.

As a product manager, you’ll usually create different roadmaps for different stakeholders. For instance, what investors and the management is keen to see is different from what developers want to know. Again, roadmaps are communication tools.

Here’s where you can read more about creating a roadmap.

Tech tool #3- Analytics tools

These could be Google Analytics, Mixpanel or Hotjar.

A good product manager knows numbers that matter

As a product manager, one of your key tasks will be to determine how your product is performing based on the goals you set for it. You cannot improve what you cannot measure. And knowing what to measure is 70% of the battle.

The metrics you set that would be the key growth indicators would inform what you will measure and the analytics tools you will use. Some analytics tools (such as Hotjar) only work on websites but not mobile apps. Others provide an overview of traffic sources but don’t go granular.

Once you decide what metrics you are optimising for, you will then choose what tool can help you measure movement. Acquainting yourself with how to read the data is expected, the ability to draw insights from that data is good, but a real MVP Product manager knows how to perform A/B tests, question the data and adjust strategy based on the insights gained from the data.

It sounds heavy now if these terms are new to you, but the more you expose yourself to these tools and processes the more your muscles grow as a result.

Tech tool #4- Agile Project/Product Management Collaboration tools

These could be Asana, JIRA or Trello

Collaboration tools give visibility to what everyone in the team is doing which helps avoid duplication of tasks and allow you to track progress on specific outputs. Most give you the option of prioritising tasks in terms of urgency while visualising dependencies. By default, a lot of tech tools have a collaborative aspect, but these specific ones are made to empower teams to work together.

Most times, you will find that your needs as the product team evolve as your product evolves. This could mean that you could start off with the simple free version of Trello and then graduate to JIRA’s premium version as your needs become more complex and all encompassing.

You will also realise that some of these tools play well with others; like Trello and JIRA are made by the same company and have adjacent use-cases (depending on what you need) so you will likely use them together. A lot of them also allow for cross-integration that enables you to embed one tool onto another so you can have all your items in one overarching tidy place.

Sometimes, you will be required to onboard onto the tool all other teams in the company are using, alongside the tools your product team uses. Again, none of these require a specialised degree to learn, but knowing their capacities and their use-cases allow you to empower your team to leverage them in ways that unlock your potential to communicate, prioritise and collaborate.

Tech tool #5 — Content repository

This could be Notion, Confluence or Google Workspace.

One thing you’re guaranteed of doing a lot of as a product manager is writing, reviewing writing or editing writing. Think of documentation as the kidney of the product. When it’s healthy, it filters out the junk and keeps the good stuff in. Because it’s easy to take for granted, you will not notice when there’s a problem until your oedematous product is full of unnecessary features no one wants.

A phenomenal product manager keeps their product documentation in order. It’s easy for whichever stakeholder to trace what they’re looking for, the information is easy to read and up to date, and the language is reflective of the audience the writing was intended for.

Tools that help you house your documentation ideally allow you to easily link pages, create sub-pages, add files of different formats and share the repository with different relevant folks. Again, different organisations will use different tools depending on the pre-existing or evolving needs.

If you’d like to learn how to create your repository as a new PM, you can read about it here.

It’s not the ‘what’, it’s the ‘why’ that matters

As a new PM, you may not always have a choice on what tools will be used in your role; that’s okay. However, it’s on you to figure out why the tool is being used and if you encounter limitations that exist with the current tool stack, you’ll have to present a case as to ‘why’ a different tool will be a better fit.

But first, learn your tools.

Product Queen™ is launching a robust, editable manual that contains templates, checklists, planners and lists that you can leverage to either land your first job as a P.M, or thrive in your current role.

​You can expect templates such as:

• The 30/60/90 day new PM checklist that got me ‘employee of the month’ in month four.
• Six product document templates you will need as a P.M [helped me create 2 years worth of scattered documents in one beautiful repository]
• How-to-guides to help you perform product-critical tasks such as doing user interviews, planning for user acceptance testing, developing the quarterly roadmap and prioritising feature requests.​

Do you want these P.M goodies from Product Queen™?

Join the Waitlist: https://www.productqueen.co/wait-list

→ Follow Product Playbook on X: https://x.com/intent/user?screen_name=jakebarlo

5 tech tools you need to be good at as a non-technical product manager was originally published in The Product Playbook on Medium, where people are continuing the conversation by highlighting and responding to this story.

My first official PM gig came after a 5-year stint running an EdTech startup that ran out of funds. While I was the de-facto Head of Product and was a master generalist, one of the key tasks that I had never gotten around to actively engaging myself with was creating product documentation on Confluence (or whatever other tool) and linking it to Jira.

So, I am writing this for the version of myself who felt overwhelmed by all the new terms and tools, who had to learn fast under the watchful eye of an overeager micro-manager who was keen to see me fail, and create the most beautiful repository of ‘main source of truth’ for the product we were building.

So, this article is meant for the PM who’s been tasked with creating and/or managing documentation, with or without the help of a Product Owner.

It all begins with the Owner’s mindset.

1. Are you starting from scratch or do you have an existing repository that you are starting with?

More likely than not, when you take on your new role, unless it’s a brand new startup, there’s documentation somewhere. It’s likely spread between obscurely-named spreadsheets and google docs, some rough notes in a book, and some lo-fi/hi-fi designs on Figma. If you’re lucky, your predecessor did a great job of organizing the information in a useful, easy-to-follow way and you can use that as ‘inspiration’ to prepare yours; no need to reinvent a perfect wheel.

Most of us are not that lucky. We’ll inherit a mountain akin to a pseudo-abandoned, dusty library that hides a lot of useful books.

Here’s how you’ll build a monument out of a documentation ruin:

a. Collect all the documentation that’s been shared with you and go through it one by one. This may sound boring, but it will help you in two main ways: you get to understand where your product came from and what it’s transitioning into. You also get to see the vision your company is looking to achieve and how you should be thinking about the place of your product in achieving that vision. A PM needs to be as close to a human manifestation of a ‘source of truth’ as possible.

b. If the documents are not properly labeled in a way that’s easy to identify and follow, create your own naming convention and save them in a private folder for now. If your company is a stickler for ‘this is how we’ve done naming before’ and it’s not (yet) understandable for you, duplicate the docs and save them with your preferred names in your own folder.

c. Determine which documents are ‘outdated’, which ones you’re not too certain are relevant, and which ones are obviously recent and up to date. One way to establish this is to check the last date it was edited/published. Another way is to check how relevant the content is to what you know is currently being built. You can then save them in three different folders. If they’re all in a Confluence or Notion Space or different spaces, you can create your own single space, add pages and subpages and separate them that way. You will confirm later with your manager whether your categorization is accurate.

d. Meet with different stakeholders within your company and outside of it. Prepare any list of questions you had after reading through the documents. Clarify things like context, competitive landscape, and current sprint and roadmap. Take copious amounts of notes; you’ll need these when creating or updating the documentation you already have. This step is important even if you were an internal transfer or hire; this time, you’ll be thinking like the world-class PM you’re becoming.

2. Who are you targeting with this documentation?

How you’ll write for investors and partners will be different from how you’ll write for developers or end users. A great PM knows their audience. For instance, main pages can contain a summary with links to pages that have more granular information. Dev tracking tools like Jira tend to go even deeper and more technical. Depending on whether or not you’re a technical PM, you’ll be focusing on ensuring your devs understand ‘what’ to build, and the techies will take care of breaking down the ‘how’.

Regardless of who you’re writing to, a rule of thumb is this: write to express NOT to impress. Fancy language is good for the ego but bad for building understanding. Make your writing simple, crisp and targeted.

Filter out the language and granularity of your writing against two main factors:

a. Who is most likely to read it (influenced by where you’ll share it or store it)

b. What key message you’d like to pass (influenced by what the specific product documentation it is)

For instance, a general roadmap meant to be shared with management will be high-level and highlight key milestone markers, while acceptance criteria to be shared with devs will have granular details on what the expected dev outcomes will be.

3. Do you have an internal source of truth, and how do you funnel information in and out of it?

A Source of Truth is a digital location that contains the most updated, most relevant information regarding a project. It’s the one place anyone can go and be confident that what's there is an accurate representation of what is current.

Most companies will have a place where a majority of their documentation lives. This could be a shared Google drive, DropBox, Notion or Confluence. For most organizations, you’ll trace even more documents distributed in other spaces like Slack, Asana, Miro, etc.

Your main first task as a potential world-class PM is ensuring that there’s reliable, updated information in a reliable location where anyone interested can find what they’re looking for, clearly labeled.

If there already is a ‘Source of Truth’, use your advantage as a new PM to test how easy to navigate and search for info is. If YOU find it hard or confusing to trace what you need or understand what a specific document is, it’s likely even more challenging for someone with less technical chops to do the same. Notice this and make improvement plans.

Find a way to have all documents feed into the Source of Truth through links, screenshots, and embeds. Everyone should know that if they find something in the Source of Truth, then it is the most updated, most relevant piece of information on that specific subject.

If there is none, work with your team to find out what is the most friction-free location that will suit the team’s needs regarding a document or information repository and get to work creating the most useful wiki that could ever be created by man.

A great PM treats whatever they’re in charge of as a product; this includes the documentation repository. Incremental improvements, over perfection is the goal here.

Next, we’ll talk about how to create and populate info in one of the most popular documentation software: Confluence.

So, what are some of the things you wish you knew when handling documentation as a first-time PM?

→ Follow Product Playbook on X: https://x.com/intent/user?screen_name=jakebarlo

Guide to creating your first documentation as a new Product Manager. Part 1 was originally published in The Product Playbook on Medium, where people are continuing the conversation by highlighting and responding to this story.

Just because you can’t code, doesn’t mean you can’t be ‘technical’:

You do not need to be the CR7 of your product, your superpower should be more focused on how you bring in the Ronaldos, Serenas and Beyoncès in your immediate team and greater org to play together. Still, for you to know how to orchestrate like the pro you are, you have to know your keyboard.

As a product manager, if you’re not growing, you’re wilting. Your basket of skills needs to keep expanding with tools, insights and techniques that you can leverage for the eagle’s view that PMs are expected to have. -PQ

Here’s some skills you need to learn so you can serve your team well:

Data Analytics

You need to be able to follow what’s happening in your product. What are the key metrics you’re optimising for and how’s the movement looking? Are your users dropping off like flies or should you be thinking about a glorious IPO and that hidden island you’ve been fantasising about.

You need to be able to segment your users, relate different datasets to pull out specific insight and more than that, you need to be able to communicate the key take-aways from those numbers and what it means for the next strategic steps.

Some great starting points to your data journey is SQL, Excel, Tableau and PowerBI. If you’d like to play around with code, dip your feet into Python and see what magic it can do for you.

You can learn these skills very affordably (or close to free) from DataCamp, LinkedIn Learning, Coursera and Udemy.

Project Management

Yes, yes… we know product management is different from project management. In an ideal world, there would be a surgically clean delineation between what you do in product and what project managers should do. However, a lot of times, you could be required to pull out some project skills to perform well.

Your ability to make product-adjacent plans with specific timelines, your knowledge of collaboration tools like Asana, Jira and Trello, budgeting resources, etc will come in handy when you have a product to run and sometimes people to manage.

You do not need a PMP certification, just arm yourself with a one-day online course that will teach you what you need to know.

User Experience Management

As a PM, your heartbeat needs to align with that of your user. You always want to build for the people who power your product. This means that as much as is possible, you need to consistently aim for excellence in the four-part User Experience test: Usable, Enjoyable, Equitable (or accessible) and useful.

While being great at this skill could include being able to wireframe user journeys on tools like Figma or Miro (or a piece of paper), a big chunk of it is your ability to talk to your users, to observe how they’re using your product (sometimes in person), to actually source for complaints about your product and to do your darnedest to polish it up into something that is delightful to use.

Google has an excellent course on User Experience Design. Check it out.

Design Thinking

I once heard a story where some non-profit went to dig a borehole in a remote desert in an African country so that they could save the women from having to walk 5km to and fro the river. Sounds really altruistic, impactful and thoughtful, innit? Except a week or so later, the brand new borehole was poisoned and the women resumed their daily 5km treks to the original water source. Wild.

Thing is, had the good non-profit folks actually talked to the women, they would know that the daily trek was their daily break. They could get together, talk girl stuff, provide emotional and social support to each other and only focus on themselves. Taking away this experience from them was not a favour. It was detrimental to their well being.

Design thinking is the process you would use to co-create solutions with your end users. It begins with empathising with your user’s needs. This could sometimes look like spending time, physically with them in their natural environment and observing how they go about their daily lives, what problems they face and how they solve them, and having non-leading conversations with them.

As a P.M, a design thinking mindset will help you build something people want, and not get your brand new well poisoned. If you have the budget, you can learn it from Harvard Online here. Or you could take this workshop from the Project Management Institute.

Remember:

Learning and Innovation go hand-in hand. The arrogance of success is to think that what you did yesterday will be sufficient for tomorrow- William Pollard.

Now, go forth and prosper :)

My name is Cindy aka Product Queen. I’m a non-coder of a PM who got promoted 8 months into my first ever official product role because of my capacity to create processes from scratch and collaborate like a boss.

Find my portfolio here where I also take product newbies through specific ways to kick ass as a new PM.

You can check out the PQ Kickstart Kit for brand new PMs here.

→ Follow Product Playbook on X: https://x.com/intent/user?screen_name=jakebarlo

4 skills you need to supercharge your performance as a non-technical product manager was originally published in The Product Playbook on Medium, where people are continuing the conversation by highlighting and responding to this story.