Many stakeholder ideas sound amazing in the moment, but deciding which ones move forward and which ones do not can give you a panic attack. Here are a few ways we keep quality ideation without being overwhelmed by quantity.

How I Prioritize Product Features From the CEO & Founder

A Simple Way to Prioritize Product Features

It was like clockwork. The CEO would message me daily, if not hourly, on new feature requests, slightly changing product direction each time. He messaged me on every communication channel you can think of: Slack, iMessage, WhatsApp, and email. Whenever it was the most convenient for him, regardless of time of day, he would send me these requests.

These emails contained not only vague future ideas, but small tweaks and non-critical bug fixes, etc. Essentially, anything that came up mid-sprint, he would send me a quick note with his ideas.

A big reason why I enjoyed working with him was his excitement about the product we were building, and he was constantly thinking of new ideas. However, that came at a cost. I was drowning in new things to build, and I didn’t know how to focus these requests.

I appreciated his willingness to share his ideas, but at the same time I had to make sure we were building the right things. I wasn’t necessarily in a position to say no to these new features, even when I was only halfway done with the features we started weeks prior. I actually did care about what he wanted to build, I just didn’t think many of these features were the right decision.

I needed to ruthlessly prioritize our feature requests.

 But, again, who was I to decide what feature was right or not? So, I thought of something to help me alleviate this pain.

After a few panic attacks, I created what I called the inbox system. This was a place in our project management board where I collected all of his, and the team’s, ideas. It gave me a chance to say, “Great idea! Let’s discuss later.” He knows that his idea isn’t lost, and I don’t feel the pressure to act immediately.

In the next sprint planning meeting, we would go through all of these ideas, weigh them against all of the other issues (i.e. features, bugs, cards) in the backlog, and prioritize the things that will have the biggest impact towards achieving our company’s objectives.

The inbox system aims to solve the problem of changing the plan mid-sprint and allows you to slow down and consider your next steps. You don't want a reactionary engineering team where the latest ideas from the stakeholders are implemented over things that have been planned for weeks.

CEO sends feature request (and wants it built ASAP).

Acknowledge her feature idea and document the request in your project management board (AKA, the “inbox”) before committing to building the idea.

During the sprint review meeting, instead of asking the validity of the idea ad nauseum, discuss the priority of this request compared to everything else that needs to be built or fixed.

It was a small tweak, but it made a substantial impact. I was heard. He was heard. And together, we made the best decision for the product and the company.

Some Features Just Aren't Worth Building, Regardless of How Genius It Is

Every feature can certainly not be a winner.

This isn’t 3rd grade where everyone gets a participation trophy and feels like a winner at the end of the soccer match.

Implementing the wrong feature can significantly impact the trajectory and traction of your app. Not just because users don’t like it, but for simply how much effort and time it took to complete.

As a Product Manager or Project Manager, you’ll get a lot of input from your stakeholders. For us, it’s our clients. For businesses, it could be your CEO or boss. It used to give me anxiety when I heard all these lofty feature requests: I felt like I needed to implement all of the ideas my CEO threw at me over email, text, or Slack.

Many ideas sound amazing in the moment, but the luster wears off quickly. If it’s still a great idea during the next sprint planning, then consider implementing it. If not, then discard it—that’s okay to do, it’s part of innovation. All ideas can’t be winners!

When you set out to build a product, there's a disconnect between what you think people need and what they actually need.

How to Define your Minimum Viable Product (MVP)

When you set out to build a product, whether it's a mobile app, website, or a physical product, you'll envision how people will use your product and what qualities they need of your product. What often happens when building products is 

If you take the Lean Startup approach to designing and building your first product, 

, you're more likely to build exactly what your users need, and eliminate waste from building features they don't need.

), and when you're building a startup company, you have real constraints with how much money and time you have to build something. These constraints force you to be smart about what you spend time building; any wasted effort could put you out of business.

The classic model to create a product is called Waterfall, and it doesn't work. With Waterfall, you start by defining all requirements, then design the product, then build it then launch it. This sounds completely logical, but problems arise if requirements change at any point in the process. 

 When this happens, your project goes way over budget and you blow past the deadline.

With a lean approach to building a product, the idea is you take the steps in Waterfall and repeat them many times over. You divide up the problem into several product phases, where each phase fully delivers on a set of objectives.

 objectives of your project. People start using your product early on in the development cycle, 

 People tell you what's working and what isn't, and you can respond by altering the product roadmap.

Think of it this way: if you set out to build a car to get people from here to there, you don't start by building a wheel. That doesn't get you to where you need to go. You could start by building a bike. From there you could build a scooter, then finally a car. At each phase of the project, people are able to use your product to achieve the main objective: transportation. They'll give you feedback along the way ("it's too slow!"), and you'll incorporate that feedback and iterate the product.

This process allows for changes in your product roadmap during active development. Changing requirements doesn't mean pushing back your delivery date - because the process accounts for change. After people use your MVP, you might decide to cut entire features, and improve other features that they actually use.

After the MVP, you'll continue iterating the product in mini releases - every week or so. The product takes shape, change by change, until you've achieved all of your objectives. The product is tested in realtime during active development, so at the end, 

you'll have confidence that you hit the mark.

At Foxbox Digital, we take a lean approach to building mobile apps. We tap into our entrepreneurial experience of building startup companies, and apply that experience to how we build products. We'll help you 

build your product with a lean, agile approach

At the end, you'll have a product that meets your objectives, has the features you need, and eliminates the features you don't actually need. 

This is how you build a product that hits the mark and deliver it on time.

mvp

2 posts tagged with “mvp”

How I Prioritize Product Features From the CEO & Founder

How to Define your Minimum Viable Product (MVP)