Product, Business, and More

Category: product

What Exactly are Product Wireframes?

For those of you new to the product management world, you may have heard the term product wireframes a few times in casual conversations. The idea isn’t really that complicated, but the process of creating product wireframes is essential (and pretty easy, too).  A product wireframe is simply a rough sketch of the thing that you hope to build. It could be a new feature, a redesign, or a completely new product / business venture. No matter what the thing you’re building, however, you should always start with a very rough product wireframe.

Step 1: Start the Product Wireframes

Remember the old KISS idiom (Keep it simple, stupid)? Remember that as you’re wireframe-ing a product. Literally grab a piece of paper, or grab a free whiteboard at work. Draw out the think that you envision, and think through all of the user scenarios that you can think of while you work. I like to limit myself to 15 minutes – mainly because I don’t want my product wireframes to get too granular just yet (and you are, after all, only on the first of many steps of the design process). After you’ve drawn out the feature as you see it, grab someone close to the product that you’re working on and talk through it. They’ll inevitably have some items to add, which is perfect – because product development is an iterative cycle, and the more minds applied, the better (Within reason, however. There is, in my opinion, a certain attrition to the usefulness of insider feedback). After you’ve completed your 15 minute session, and grabbed a companion to vet out your rough concept, take a few photos of your drawings – and now sleep on it, and revisit the wireframes once more before you finalize the rough concept.

Sample Pencil Paper Product Wireframes

Sample Pencil Paper Product Wireframes

Step 2: Gather the Stakeholders

If you’re building a feature or a new product, there are usually other people involved. At this point in the game, I like to gather the troops and make sure that there are no other opinions that may have been missed in your independent brainstorming session with your other product buddy. It’s important that you invite anyone to this meeting that may have some kind of final say in the way that this feature or product is developed. Getting their feedback and buy in early in the design process is hugely important. Knowing everyone’s must haves as soon as possible will lead to a more complete feature, saving everyone time and money. For some companies this may include your CEO, CTO,  PMs, Sales, other teams that might be a part of an integration, etc. Keep this meeting very high level, and frame it as a discovery meeting. If you want, you can show them the photos of your beautiful drawings, but it’s not mandatory. That step is more to help you gather your thoughts before you meet with the others.

Step 3: It’s Time for Product Specs

Take the information that you just gathered, and make sure that you’re collecting all of the information somewhere. I prefer confluence for my product specs,  mainly because it’s simple, easy to use, and it integrates nicely with JIRA, a software product management platform. If confluence seems like too much extra work for you at this stage of the game, just use your Mac Notes or a Google Doc. The important part is that as you gather requirements and feedback, that you’re saving it all in one place. Don’t get into the nitty gritty of your product specs just yet, but instead, use the product pages as a place to list everything that you’ve learned, and any open questions that you may still have.

Step 4: Digitize the Product Wireframes

Now that you’ve slept on the rough sketch, gathered more feedback from others, and begun to spec out your budding feature, it’s time to digitize the thing. Use a wireframe software system (Like Balsamiq or Adobe XD) to kick off a digital version of your brainchild. This will make explaining your idea to others far more simple, and will also be a great next step for professional designs. As you spec out the rough wireframes and general user experience, make sure to document what is and is not necessary as you plan out your product (Aren’t you glad that you have a product page for that?). This is when I typically start itemizing some of the dev work that will be required into my more formal product specs – but remember, your final designs may change the look and feel of the thing that you’re creating, so stay away from too detailed of wireframes for now. Instead, focus on the data that you need, the system requirements, the integrated functionality, and all the other mumbo jumbo that comes along with a product.

Sample Product Wireframes

Sample Product Wireframes (#1)

Sample Product Wireframes

Sample Product Wireframes (#2)

Step 5: The Product Deep Dive

I won’t go into a ton of detail on the deep dive into a product kickoff, but will instead congratulate you – because you just completed the necessary steps to create product wireframes! Remember, now that you have a rough look and feel of the product, I’d again let key stakeholders review the wireframes. Just let them provide some quick feedback – and then you can send them off to design!

While the process of creating product wireframes isn’t too exhausting or too crazy, it is an essential part of any product’s development. Make sure that you perform each of the steps above. I’ve found that while it can be easier to skip some of these steps, doing so will just create pain later in your product development process. This makes the feature or product take longer to develop, leads to more unintended ‘updates’, and simple slow you down and dishearten your team. Make your mocks, get your feedback, and you’re off to the races!

Managing a Product Backlog

A Jar of Rocks – a Product Backlog Analogy

I was in a meeting with my manager the other day, and he said something that really stuck with me – he said that I needed to make sure that I was thinking of the product backlog as a jar of rocks. He went on to recount the story that we all heard back in 5th grade science class, and reminded me that the order in which you put the rocks into the jar matters! It directly determines how many rocks you will be able to fit into your jar. You have to start with the big rocks, and then pour in the sand to fill up the rest of the jar. If you do it the opposite way, and start with the sand, you’ll never be able to fit all of the big rocks in.

This directly applies to planning items that will be worked in future sprints. Start with the big rocks, and then pour in a little sand each time. The rocks being big feature components, and the sand being the little fixes and small things that can wait.

What’s a product backlog?

For those of you that are not familiar with product management, a backlog is essentially your list of things to do, broken down in digestible chunks of  work. If you’re using tools like JIRA then you can then sort the items from top to bottom, with the most important things on top, and the less important items on the bottom. The top / bottom ranking, in my opinion, is very valuable because it forces you to rank items in the order that they will be completed. It sets clear expectations of what and when something will be worked.

How to manage a product backlog?

Managing the items in a product backlog can be really really hard. That’s simply because you usually have waring stakeholders – business people want business things, data people want data things, and your users typically want a completely different list of items. As a product manager, you’ll always have to balance the demand of different stakeholders – and this really comes to light when you’re planning the work on the backlog.

I always start with priority of the items on the backlog first. ‘Blockers’ are the first items that you should complete. A blocker is something that breaks some core functionality of the product, and it typically prevents some user from being able to complete their core task. That could be a serious data error that prevents Business Intelligence from being able to run an analysis, a product user from being able to complete their core function, or something equally as bad. A blocker is NOT something that someone simply wants, but it should instead have some serious implication that can be easily measured or seen by many users. Blockers are typically shipped outside of sprints, in a hot fix release.

After you get past any known blockers, you have to start with the ‘big rocks’ that are in your product backlog. These are the features or items that you know will help improve the product or meet some new business objective. They are typically larger items that will take one engineer most of a sprint. Put these items at the top of the product backlog first, and then start squeezing in the smaller items. Some of those smaller items might be user interface bugs, text change requests, and other small tweaks that will usually take a small amount of time for an engineer to complete.

Sorting out your backlog in this way will really help your team stay focused and complete the items that are core to your product’s value prop. Filling in the remaining free time with smaller fixes will create some little wins along the way, as well.

How to groom a product backlog?

If there’s one constant in product management, it’s change. Anyone that’s ever worked on any software development team knows that change – and they change regularly. This means that your backlog should also change regularly! I suggest that every week you review the backlog with your lead dev, and / or any other essential stakeholder. You can then review the items that are on the backlog, and move them up or down as the team sees fit. Performing a backlog groom regularly will help make sure that the team is focusing on the items that are truly necessary, and will keep the sand from building up. Remember, blockers stay in the number one spot – so if you find your team shuffling it downwards, it’s probably not truly a blocker. If that happens, bump it’s priority downward.

Having your product backlog nicely groomed will make sprint planning with your engineers go even easier, as well. When your team can clearly see what’s going on, and they know exactly what they should be tackling, you will see your velocity increase – which is what every product manager wants!

As the product manager, you’re in charge of the process and the flow of the team. Having a clean and ordered product backlog creates a clear list of objectives and tasks that teams can then easily work their way down. This provides clear insight into what needs to be accomplished to the team, external stakeholders, and yourself. As you’re reviewing the product backlog, make sure that you see plenty of big rocks, with the little stuff squeezed in around the edges.

Analyzing a Product: The Must Ask Questions

I was recently asked to analyze a product that someone was building, and it left me wondering how exactly I would explain the process to a non product person. It seemed like this interaction could make a nice blog, so without further ado, here’s my two cents on the questions you should think through when you’re analyzing a product:

Analyzing a Product: The Basics Questions

Ask “Why.”

If you’ve read some of my past blogs, then you already know that you should always start with a why. Why would someone use this product? Starting with this simple question, you’ll begin to force the person that you’re speaking with to boil down the idea. This will help you better understand what pain point they’re trying to solve, which in turn will help you craft a product that truly meets a need.

Who will use this product?

If the “why” didn’t get you there, it’s usually helpful to ask who explicitly the creator sees as being the primary user of the product. I dare you to think through the answer that you’re given, and make sure that the persona identified has the need described in the “why.” Identifying the “who” will also help you confirm if the product should be  a web product, a mobile product, etc. Knowing who the intended target of a product is will be essential in your process of analyzing a product.

What do you think your customers want?

People who are developing products in their free time have a tendency to only show their creations to their closest of friends. Which means, some of these core questions are rarely thought that far out. So, when you ask these questions, I would recommend that you dig in a bit. Don’t take the defined target as accurate or right – but instead challenge the person you’re speaking with a bit. If they say that their target market are young moms, think through the user with them, and challenge them on if it’s the right market. This will help you surface thoughts that the person you’re speaking with has been thinking, but hasn’t explicitly said yet, which will ultimately help get you to the core of the product even faster.

Analyzing a Product: Identifying the Problem

What problems will this product help a user solve?

I am a firm believer that people use products to solve some problem. So, when analyzing a product, it’s essential to identify this problem as immediately as possible. If a core problem cannot be identified, then this product might not have a true need – which means that it will most likely not be a successful product. Sometimes the problem is not as ‘surface-level’ as you’d hope, but dig into why the person created the product in the first place, and you might stumble upon the core problems that users face.


Analyzing a Product: Reviewing the Competition

What are the existing products lacking?

When analyzing a product, you have to ask what the existing products on the market lack. This will help you get to the core of the value prop, which is truly the heart of the product and it’s resonating message to future users.

What other products on the market would a user consider using instead of your product?

This question is really just to see what the creators used as their early ‘vision’. Knowing this will help you learn about the creators, and also help you understand the look and feel of their original inspiration. It can also help you more quickly identify if the V1 of the product should be mobile or desktop.


Analyzing a Product: The Switch

What would help motivate someone to switch to your product?

Why the heck would someone use the product!? There better be a dang good answer here – because if there’s not, then you know the product is going to fall flat on its face. This again gets at the value prop of the product. Can you tell how important getting a well rounded answer here is?

Would the user even consider using your product if they are already using a competitors? 

This question is typically a good followup question to the one above – only because it forces the creator to really emphasize the core value prop one again, and usually more concisely than the first answer.

How difficult is it for the user to switch from the other product?

Switching is terrible. There’s a reason we all keep the same crappy cable contracts, cell phones, etc, and that’s because switching is hard! You’ve invested time into all of the things that you use… so why would you be willing to go through this painful period again? Getting to the crux of this question will again force the creator on the idea of the value prop. At this point, if you feel like you have a good impression of the value prop, you can leave this one out.

Analyzing a Product: A Few Other Thoughts

Have you asked many people about your product? What do they say?

Creators should be asking everyone about their products! If they’re not, then they’re afraid of something – and if they’re afraid of something, then they typically know something that they’re not telling you.

What would you Google to find this business?

This one is more about helping the creator boil their concept down to a few word phrase. This is again about getting at the value prop – which is essential for the creator, and the product person! You must know what drives your user!

Analyzing a Product: That’s All!

There you have it! The above are the initial questions that I typically ask when reviewing a product with someone. These questions are only intended to be guiding questions, and they are by no means a required list of questions that you must ask in a certain order – instead, they’re just guiding questions that you can use to help get to the core of a product, and better feel out the creator of the product. Have fun analyzing products, and let me know if you ever have an additional questions!

People use products for a reason.

My main questions for every product development project that I work on are variations of “why”? Why was the product built? Why is the product needed? Why will the product continue to be needed? Why would someone choose this product over some other competitor out there? I don’t ask these questions to pester the creator, but more, to make sure that they themselves understand their “why”.

Figure out why people use your product.

Getting to “why” in the various situations above can be hard, but it’s an essential to defining the core essence of your product. You need to have a “why”. It will help you understand who uses your product, where they use it, when they’ll use it, and many other factors that will help craft other elements of your product – like its design, its development strategy, and more.

As cheesy as it might be to plug a Ted Talk, while we’re on the question “Why” I have to plug Simon Sinek:

Getting to “why” isn’t an option.

it’s an essential part of any product development strategy. If you know your why, your customers will innately ‘feel’ it. This will lead to a unified vision within your company, will reduce product confusion between key stakeholders, and will indirectly translate into greater sales and profits. It will also help keep your features and development scopes in line – because instead of running off on tangents, the “why” will act as a glowing light that keeps you on the right path. It will become the basis of your vision, and will unify your team and different business groups.

So, without further ado, can you tell me your company’s “why”? Is it at the core of your product development strategies? If it’s not, get there fast – because without a solid “why,” you’ll be left wondering “how” things got so far from your original goal!


© 2024 Michael Bryan Ross

Theme by Anders NorenUp ↑