A product spec is a blueprint that describes what you’re building, who you’re building it for and what the final outcome should be.

A well-written spec is about clarity. The more information you have going into a product spec, the more clarity you give everyone working on the product with you.

We generally include some or all of the following, depending on what is needed to clearly communicate what is needed.

A product spec includes:

• Summary – what is the idea being suggested?
• A business case – what value does this create for the business and/or customer?
• User stories – what is the user trying to accomplish? (we have a quick template here)
• User personas – who is the solution for?
• Designs – what does the solution look like?
• Functional specs – what are the technical details behind the solution?  (Joel Spolsky has written extensively about this.)

If you’re working in a bigger company or large teams, you should err on the side of over-communication: more context and more deeply detailed specs. As a rule of thumb, the more moving parts that are involved, the less you want to leave up to interpretation.

On the other hand, if you’re working closely with a small team, you might be able to get by with simpler, lightweight specs.

Our 5-Step Process For Writing Product Specs

For much of its life, a product spec is a work in progress. That’s fine! That’s how it should be. You’ll be getting new information and dealing with potential setbacks  throughout the process.

We follow a process here at ProdPad that mirrors something Einstein once said: “If I had an hour to solve a problem, I’d spend 55 minutes thinking about the problem and 5 minutes thinking about solutions.”

Thinking through the problem that you intend to solve – and sometimes even going back to the drawing board entirely – is not a waste of time. The problem is usually the hardest thing to nail.

So expect that you’ll probably be making a series of changes to make along the way – but also that you’ll end up with a more solid product spec for it.

Writing specs is not a straight shot – but here’s the process that works for us.

Step 1: Turn to customer feedback and data to find the source of the problems

The best place to go looking for problems is in your customer feedback.

Customer feedback comes in many forms: complaints, questions, product suggestions and  feature requests. The most critical thing when evaluating all this is to not take it literally.

What your customers are asking for is not a mandate. When you’re investigating a problem area,  each item of feedback is a data point to help you get down to the root of the problem.

Speaking of data, customer feedback won’t always tell you if something critical like the checkout flow isn’t working. You’ll often need to look at the data!

What’s behind all this feedback in the first place?  What is the underlying issue here? These are the kind of critical questions that help you understand  a) the problem and b) the scope.

Other questions to ask here:

• Are a lot of customers asking for this? How big is customer desire?
• How critical is this problem? Is this going to make it hard for you to win over future customers?
• Is it keeping you from acquiring more users or closing deals?

Step 2: Break the problem down into a bunch of hypotheses

So how big is this problem, actually? In this step, you’ll continue to understand the scope of what you’re dealing with.

Let’s say for example, your customer feedback tells you that you have a big problem on your hands. There’s no quick fix for this one. You need to completely redo your checkout process.

Now you’re probably considering all kinds of ideas and that can quickly start to get overwhelming. What we suggest is that you break these ideas out into three categories:

This way you can still account for the full scope of the problem, but keep your eyes on the ball. Think MVP. The essentials are your top priority. Everything else is going to have to wait its turn.

Step 3: Open up product discussions across your team/company

“Writing a spec is a great way to nail down all those irritating design decisions, large and small, that get covered up if you don’t have a spec. Even small decisions can get nailed down with a spec,” says Joel Spolsky of Fog Creek Software.

Oof, yes. That sounds familiar. However, those small decisions tend to add up – and it’s in no one’s best interests to start dealing with them when it’s already sitting in your dev backlog.

The mistake I’ve seen made over and over is leaving these discussions until the end when a spec is already in production. You must create a space and a forum for your internal stakeholders to contribute while the idea is still taking shape.

Start inviting colleagues around the company now to help you start getting your idea ready. They know things you don’t and they can tell you from their corner:

1. What works
2. What doesn’t work
3. Argue for a bigger/smaller scope

The opportunity to open up product discussions around what gets done and how is a key trait of effective product teams.

We keep all our product discussions in ProdPad. Each product idea has a discussion section, so we’re able to focus on really specific objections and concerns.

Step 4: Do user testing with your closest customers

Everything you’ve done so far makes sense on paper, but reality bites. Things change when you put a prototype in front of humans! It’s time to see whether your assumptions hold and your customers react the way you’ve imagined they will.

At ProdPad, our designer preps  a series of simple designs – really simple, like wireframes and clickable prototypes – for user testing.

We do our user testing in two ways usually:

1. Slack customer community – We throw designs into our customer community and invite feedback. It’s a public channel, but it’s also where our closest and most engaged customers hang out. We get a lot of insights from the discussions that follow.
2. One-on-one user tests – We set up a dedicated session where we ask our user tester to perform a series of tasks to see how/where they trip up

Can users complete the tasks you ask them to? Are they easily able to find buttons? Do they feel confident about where to look for stuff?

What usually follows is that some of your assumptions were wrong. It’s not as easy to find the buttons, or the flow isn’t as obvious to the user as you thought it was.

There’s a couple other surprises you may find out here:

• edge cases
• surprise requirements
• misunderstood functionality
• widened or changed scope

At this point, we’re also looking at the bigger picture. We also look at how the new solution fits in with the way our users already use the product. What’s the difference between changing nothing and putting something new in place?

But it’s just a prototype and all you have to do is adjust it. Repeat until you’re confident you’ve gotten it right.

So think of it this way: User testing is all about minimizing risks. It’s cheaper to repeat this step than go live with a new feature that could blow up in everyone’s faces.

Step 5: If it’s ready, send to development

Remember how I mentioned earlier that product specs are always a work in progress? That’s the case even now, here in this final step.

The, even if development goes flawlessly, QA is a diff story.  Once you start clicking around, you might start to discover little things that you may have missed. It’s okay not to be harsh on yourself – it happens even to us.

We think everything is great and pat ourselves on the back for being so meticulous. But when we’re testing, we think, “Hmm, maybe this button should be on the right because it doesn’t actually make sense in the context of the rest of the app.”

It happens to the best of us. Perfection takes time.

When you feel confident you’ve got something going, add the final touches: final prototypes, technical information, key context, etc.

If you’ve been developing your product spec in ProdPad, now you can simply push to Trello, JIRA or your development tool of choice.

All done! Now take a well-deserved break and when you’re back, go right back to where you started from: customer feedback. The life of a product manager, eh? 

The post How to Write Great Product Specs appeared first on ProdPad.

• Build A House
  • Build the foundations
    • Lay concrete
  • Put up the walls
    • etc.
  • etc.

We ran with this analogy to help explain how a roadmap works, and how elements in ProdPad can be used to put it together:

Build a House

This happens at the Product level: You would create a product in ProdPad, and give it a vision, KPIs, etc. in the Product Canvas. Once done, you’d then open up the Roadmap for this product, where you can build out the rest.

Build the foundations, Put up the walls

This maps well to the roadmap card level: You would then create roadmap cards in the appropriate columns for each of these high-level projects.

Lay concrete

This is at the idea/feature level: Here, you’d create Ideas to represent these sorts of features, and attach them to the roadmap. You can create ideas from any page, using the button at the top, and then attach them to the roadmap either from the idea itself, or on the roadmap card itself.

We can then take this to the next level down, too:

Mix concrete, pour concrete, watch concrete dry

For more detail, you can break your ideas into User Stories. These are in the Specs section of any idea page. These user stories can be attached to the roadmap individually as well – it just depends on how much detail you feel you need to go into to communicate to the rest of the team what needs to be done.

Typically, the cards in the ‘Future’ column will be higher level and have less detail added to them than the ‘Current’ column. Also, if you need to consider a wider set of products, you can create Product Lines and group your products into them. For example:

• Build a Housing Complex (Product Line)
  • Build House A
  • Build House B
  • Build House C (Products)
    • Build the foundations (Roadmap Card)
      • Lay concrete (Idea)
        • Mix concrete (User story)
        • Pour concrete (User story)
        • etc.
    • Put up the walls (Roadmap Card)
      • etc.

Do you have any suggestions on how you structure your product roadmap? Discuss with us in the comments below or at @ProdPad

The post How Structuring a Roadmap is like Building a House appeared first on ProdPad.

The post Integrate, integrate, and integrate? Building Products for a Connected World appeared first on ProdPad.

Open Communication

Good idea management requires communication input from many different sources. With departments like legal and compliance this might be irregular or limited to specific details, but the specialist information they hold could seal the fate of new product ideas. Using ProdPad you can extend collaboration to absolutely anyone in your organisation without having to integrate them as a fully fledged user. Tools like Google Single Sign-On and email integration mean that it’s easy to call on colleagues for advice whenever it’s relevant, using @mentions. Comments can be dropped directly onto idea canvases and design mockups, so that pertinent information to an idea is accessible to everyone in your team.

Product Compliance: Impact vs Effort

Judging whether a new product idea is feasible is dependent on the big picture. Value brought to the business needs to be set against the effort or risk involved across the entire product process, not just development resources. Taking what you’ve learnt from conversations with compliance and legal, you can make an educated guess of anticipated effort to take a new product idea through to launch and set that against the business case and estimated value. ProdPad allows you to do this for every new idea using various scales including an adjusted Fibonacci scale, all of which is plotted on a visualized priorities chart.

Specs from every angle

Build product specs that take every factor into account. An important part of preparing requirements that are 100% ready for engineers and designers is to note any compliance concerns. Providing this information from the start will help you to avoid do-overs further down the line. ProdPad idea canvases provide a comprehensive template for the data your development team needs, including technical specifications. And with two-way integrations between ProdPad and project management tools, your developers can follow links to get all details of legal and compliant regulations shared directly by these teams.

Fully Audited Processes

Some regulations require that product processes are completely audited. When you manage all conversations, user feedback and design iterations in one centralized platform no details are lost, keeping your compliance and legal teams happy without any extra workload.

If you’d like to chat to us about how you can make product management processes more compliant using ProdPad, get in touch here. 

And if you’re new to ProdPad, you can sign up for a free trial here. 

The post How Product Managers Can Keep Product Compliance and Legal Happy appeared first on ProdPad.

Source valuable feedback from the field

Your sales or business development people are your commercial ears on the ground – they have daily conversations with prospects about what would encourage them to buy. Ideas and suggestions often come thick and fast from sales teams, so it’s important to be able to validate the ones of real value. ProdPad distinguishes user feedback from the ideas list so that every valuable piece of information can be captured while reserving the product backlog for specific suggestions and ideas. Sales teams can use tools that fit into their own daily jobs to share those suggestions, from email to Google Chrome.

Get commercial input to decisions

Collaboration doesn’t stop as soon as an idea is marked out as having potential. Defining user requirements and a business case for development can often rely heavily on the input of your commercial team. ProdPad’s in-tool communication allows your sales team to share comments on any idea canvas, and product managers can reach out for specific information directly through @mentions. A simple voting mechanism for idea canvases means that opinions for and against different features can be measured and business development teams can be assured their input is heard.

Help keep prospects and customers in the loop

Your sales team is not only a mouthpiece for customer opinion, but can be an important link back to users and prospects to keep them informed about upcoming product changes. ProdPad roadmaps focus on current, near-team and future developments, allowing you and your sales team to give safe projections for what’s in the pipeline. Cards can be made public or private to prepare your sales team with a roadmap that’s appropriate to share externally via PNG or PDF exports or even a live site embed.

Individual salespeople can follow ideas to remain updated on feature progress all the way through to implementation. And when ProdPad is integrated with project management tools, these updates are completely automated, meaning your sales team need to do nothing more than await the latest email notifications.

Catch up on how to involve executives in product management decisions here, and stay tuned for the next instalment where we take you through how to involve marketing in product planning.

If you’d like to see how ProdPad can help you to open up product management to Sales, you can sign up for a free 14 day trial here. 

The post How to Open Product Management to Your Sales Team appeared first on ProdPad.

Prompts for best practice product specs

A ProdPad idea canvas comes complete with cues for all the information you need to determine whether a new idea is viable, and to transfer it to development for implementation. This helps to guide your team through idea management, to ensure that nothing is either missing or misleading. But building up complete product specs takes time and can’t be put together in one swoop. Automated prompts to revisit ideas that are missing detail help product managers to stay on top of triage without repeatedly trawling the backlog.

Open communication in one place

The diverse information needed to prepare a new idea for development often requires the input of several different people. ProdPad keeps your team updated on ideas that are in the works, allows them to comment directly onto an idea canvas, and to pull in others for help with @mentions. And communication via ProdPad comments can be done right from the email inbox, without even having to log in. All collaborative changes to an idea are logged in the ProdPad system, so product managers can stay on top.  No more lost documentation, forgotten conversations or untracked edits.

Centralization without disruption

Centralizing as much as possible into your product management system is the best way to coordinate the diverse information that goes into a good product spec. But not all processes can or should be readapted. ProdPad allows you to attach any external files to an idea canvas, from documents to design mockups, so that you can keep everything together without sacrificing the quality of information you collect.

If you’d like to find out more about how ProdPad fits in for building product specs, you can sign up for a free trial today.

If you missed it last week, catch up on How ProdPad Fits In: Capturing Ideas. And next week, read about how ProdPad works alongside your existing processes to share product ideas with colleagues and customers.

The post How ProdPad Fits In: Turning Ideas to Product Specs appeared first on ProdPad.