Member Article

How to make timely decisions in product development

By Matthias Dittrich, Creative Director, argodesign

For many businesses, challenging economic circumstances are putting teams in every department under pressure. Product development is no exception to this trend, with many teams now needing to rapidly make decisions amid market conditions that change by the day.

Whether it’s selecting initial features, laying out product vision, creating a minimal viable product (MVP), or iterating on a product already on the market, many product teams find themselves making major decisions under compressed timelines and difficult operational circumstances. At the same time, however, rushing these decisions can prove very costly for a product and business, with the long-run effects of a poor choice lingering for years.

To avoid the risk of either falling behind or making an ill-judged decision, you need to be aware of three things when it comes to product development: project requirements, the circumstances within and among clients and customers, and the state of the broader market. Then, you need to find a way to systematically break down your level of knowledge and find out what you’re confident with.

Looking at project requirements

Even when you’re working from a detailed project brief, you and your team will often have to dig deeper to make sure you deliver the product that meets the needs of a client.

One of the first questions you should always ask yourself is what exact user needs you’re trying to cover with your product. What a client has told you so far is a very useful source of information, but often it’s also accompanied by tacit needs.

Say, for example, a client has asked for a platform that helps the sales and business development teams manage leads, you should dig deeper and think about what the company and users will need to make this platform a success. In this case, the client needs a platform which is thorough in fetching and managing leads, while also being accessible to non-technical members of the business development and sales teams. Having these two needs at hand will help tremendously in making many decisions for how the project should turn out.

It’s also important to think about the end-goal of a product. Something that can be neglected in a brief is the extent to which a product will benefit a business as a whole, and it’s important for a team to think about this to consider additions or features they should make. For example, going back to the lead management platform, the key end-goals of such a project for a business would be to find new leads, generate conversions, and assist in preventing churn of existing customers.

The internal context

Additionally, you will need to think of the internal context of the organisation you’re designing for. A product should fit in with an organisation’s vision, business model, technology stack, existing solutions, and have buy-in from people among the team.

You should research the skills and infrastructure of an organisation’s technical team to see if they can realise a project, and use what you find to inform your design decisions. Think about how a product can tie in to technology they already use, and if there exists a solution within the organisation you can use as a template for your own product.

Additionally, there are the things which are more difficult to measure - how an organisation’s vision, people, and business model might impact the development of a product. Consider if any of these things could possibly inform a product, and if so how to tweak a design to reflect these facts.

Examining the market

Afterwards, you should consider turning your attention to the market as a whole beyond the internal context of an organisation. Consider what niche your product would occupy, which in turn should provide useful information regarding the expectations of users and customers.

You should use market data to help set the benchmarks that clients and users will be looking at to measure a product’s effectiveness. Don’t be afraid to borrow best practices from existing products, and also consider how other similar products have fallen short and what you can do to avoid repeating these mistakes.

Bringing your knowledge together

After thinking about project requirements, the internal context, and the market as a whole you should have covered all the bases you need to make a decision.

But how can you be confident about your knowledge so that you can settle on a decision? The best way to go about this is through externalising and codifying your level of knowledge in each of the above domains - the project, the internal context, and the market as a whole. You should consider what it is that you know and don’t know, and classify it along the Known-Unknown matrix, which classifies your current stock of knowledge into four states:

• Known knowns - everything that is factually known and has been proven to us
• Known unknowns - everything we assume, but have no proof or evidence for
• Unknown knowns - the biases and prejudices of ourselves and other peoples
• Unknown unknowns - everything that could happen but we’ve yet to identify

Once you’ve assessed where your knowledge sits in the Known-Unknown matrix, you should be in a much stronger position to find a “sweet spot” where you’ve optimised for timeliness and thoroughness.

Once you’ve ensured you’ve learned all the relevant “known knowns” and hardened a sufficient amount “known unknowns’’, you should turn to your “unknown knowns” and appraise them - ie, make sure you’ve clarified all the relevant agendas or biases of stakeholders in your project. When you feel your current stock of “known knowns” and “unknown knowns” lines up with the expectations set by the “unknown knowns”, you’re usually in a place to make an adequate decision. In this way teams can make sure their decisions are as comprehensive as is necessary, but as swift as is possible.

This was posted in Bdaily's Members' News section by argodesign .