On every new software product, feature or project you develop you are bound to come across challenges that don’t have a clear answer at first. In an effort to resolve them you likely hold some discussions with your team, consult some people who might know the answer and you might even prepare some bullet points or slides. Yet you still can’t get to an answer that works or an answer that everyone agrees on. Worst case scenario, you’ve alienated or angered people in the process. After working through countless challenges of different shapes and sizes, from the technical to the commercial, to the political, I’ve arrived at a tool for working them through that stems from my scientist parents. The approach is to write out the problem you’re facing following the structure and form of a scientific research article. This might take anywhere from 15 minutes to several days involving multiple workshops as well as research and experiments. For those with a science degree, I want to clarify that this article may deviate from best practice in the production of a scientific paper or applying the scientific method. However I’m unashamedly referencing a “scientific paper” and the “scientific method” because of the shift in mindset I’ve observed that these words bring that gain a noticeable improvement in the end result. Why take this approach? The benefits of this approach are: It forces you to clearly articulate the problem (which is often the hardest part and, once written reveals the solution). It means you lay out the data, the facts, the context and the background which puts everyone involved on the same page, reducing the risk of putting people offside. It forces you to describe an approach to resolving the problem you are facing.It helps document the way the problem was discussed and resolved so you can refer back to it later (often necessary). It helps you articulate the assumptions you are making and the risks you will be taking. Ultimately it helps you those around you form a more objective view. and Step 1: Create a document for your problem Create a document, page (if you’re on a wiki) or heading (if you already have a doc) with a structure that closely follows the way a scientific paper would be structured. You can speed this up by downloading a template we’ve created for you at the bottom of this document. The table below shows the sections (headings) you will use next to the sections typically found in a scientific paper along with an explanation of what the section is for. Step 2: Give Context and State the Problem After you have your headings in your document the real work begins. In this step you need to give some background and context to the problem that you are facing. In giving context, it is often helpful to state or restate the organisational, product or project goals that are most related to your problem. You also want to provide any constraints (e.g. budget, timelines) that relate to your problem. Pro tip: If you’re getting stuck here or anywhere else then just write exactly what is in your head. Don’t filter it, be self-conscious about it or worry about whether it is right. Get it down. Then refine. This approach allows for stating things and then explaining why they don’t work. If you’re doing this then you’re winning. With your context in place, you now need to clearly state your problem. The better your problem statement the faster you’ll find the right solution. So don’t be afraid to spend time here. Before you state your problem you may need to outline the ways in which the context gives rise to the problem. This will help link the problem to context which can come in handy when you’re trying to solve the problem. The more objective and factual you are with your goals, constraints and other areas of background the easier the rest of your work is. Linking the context and the problem like this will help you better articulate your problem. Sometimes, just by making a clear link the solution has immediately emerged or, often, some solutions are immediately disqualified. Personal note: For me this is one of the delightful and rewarding ways to solve a problem. Articulating the context and problem so well that certain solutions are logically disqualified…. Magic. As you work on articulating your problem, write out the discussion points and arguments evolving in your mind. Doing this will help you work through the nature of the problem itself and the considerations that you need to make. It will also provide you with something you can circulate with others for feedback and further discussion. If in doubt, write it out. If you haven’t had that moment of delight where your problem is solved just by articulating your problem clearly then you will need to keep working. Step 3: Information Review Your next step is to review the information that is readily available to you. In science this is reviewing the work of others. In software development land this is reviewing the work of others (like a colleague or third-party researcher) and also reviewing the data that you can easily access (like data from your analytics tools or database). As you review the data make notes on what you find and why it is or isn’t relevant. What you find doesn’t necessarily have to be insightful, it can just be restating facts. This is important because, although it might be something you know, it may be new information for someone else that you need to collaborate with to solve the problem. Part of your job here is to uncover information so that others can more easily help you and your team solve a problem. At the end of this step you may want to review your background or problem statement. You may be able to disqualify certain solutions or resolve the problem completely. Step 4: Design and run an experiment If you have been unable to truly understand the nature of the problem or arrive at a solution by this stage then you may need to design and run an experiment to solve the problem. Designing and running an experiment is a bit beyond the scope of this article but if you just do these four things you will be on the right track: Plan – write this in your section Methodology Write out what you need to prove or disprove (what you want to learn) Write out the process you will take to prove/disprove Do it – follow the process you wrote out. Write down what happens in the section. Results Pro tip: when dealing with a more political problem like getting alignment or change of mind from a stakeholder then you may want to rename this section from ‘Experiment’ to ‘Approach’. Step 5: Summarise and/or Repeat You can now review your problem and your solutions. If you’ve managed to solve them you can summarise in the section. If you haven’t then you will want to summarise where you landed then repeat this process. Summary Keep the Summary itself to 1-2 paragraphs. If someone needs more information then they can keep reading. section A closing collection of tips Now that you have the substance of it, here are a few minor tips to help you through these steps: Make sure you keep versions and, where-ever possible, keep everything you write in the document somehow. It helps. Even if you add an appendix or notes section to the end. Seeing how you thought previously, how others thought or paths not to follow is quite useful. Practice makes perfect; don’t expect to nail this approach first go. At first it may seem like extra effort. However, over time those that I’ve helped to follow this have found their thinking evolve where they may no longer need the structure or the document and they naturally start to layout arguments in this way. Avoid superlatives, colourful language and exaggeration. Some examples:Don’t say “it needs to be really fast” state exactly how fast it must be (and define exactly what is)Don’t say “we need to support of users” state exactly how many users in what time frames. it lots Avoid “recommending” anything (e.g. “I recommend”, “We recommend”, “Company X recommends” or “the usual approach is” or “in my opinion…”). If you’ve done this exercise properly the logic will speak for itself. You won’t need to recommend, express opinion or draw upon some theoretically authoritative figure like “the usual” or “Company X”. Don’t assume prior knowledge. Don’t assume everyone is aware of what you are aware of. Describe things in plain terms from the beginning. Get down to first principles or second order thinking I've created a template to get you going with this method which you can download from our website . here Previously published at https://www.terem.com.au/blog/how-to-solve-engineering-problems-with-the-scientific-method/

Different

Keep

Mind

Who is Product Engineer

How to Solve Engineering Problems Using Scientific Method

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

4 Reasons You Shouldn't Use MoSCoW for Product Prioritization

10 Knowledge Base Software Best Practice Examples

5 reasons to ditch the paper and start document automation

5 Software Documentation Tools That Make Managing Technical Documentation Easier

6 Ways Digital Document Management Will Empower Your Business

62 Stories To Learn About Documentation

4 Reasons You Shouldn't Use MoSCoW for Product Prioritization

10 Knowledge Base Software Best Practice Examples

5 reasons to ditch the paper and start document automation

5 Software Documentation Tools That Make Managing Technical Documentation Easier

6 Ways Digital Document Management Will Empower Your Business

62 Stories To Learn About Documentation

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps