Which drives the development stories (short term; Hours\/days)<\/li>\n<\/ul>\nThe business objective is in itself a problem to be solved. This ties into the product statement, the raison d’etre for our product within the context of the business. This product statement is again a problem, tied back to the business objective. The product statement is then broken down into a series of goals or objectives to be achieved over a period of time, with measurable KPIs tied to them. These in turn are broken into even smaller problems which can be plotted into a problem roadmap, problems which the team can endeavor to solve and measure by the implementation of user stories, again aligned back to the product goal, which aligns to the product statement, which aligns to the business objective.<\/p>\n
This structure offers every member of the team traceability for each piece of work they do, back to the very high level business objective that is driving the development. And this structure is incredibly important; being able to articulate a business objective into practical problems to solve is key to ensuring that the things we build are aligned to the reasons that the product exists to begin with. Getting this wrong can leave teams trying to achieve the (mission) impossible, which can cause team morale to dip and belief in the product team to falter, as KPIs routinely fall short.<\/p>\n
Let’s take a stab at this: company X sells shoes online. They have no physical stores, but they prop up their direct web sales with retail profiles on Amazon and eBay. The business objective is to Increase sales by 20% for the financial year<\/strong>. Within this business model we have several products; a website, and shops on eBay and Amazon. Each of these ‘products’ should have it’s own product statement, so let’s take the example of the eBay shop. Their product statement might be\u00a0To offer the most competitive alternative to buying second-hand shoes via an online marketplace<\/strong>. This aligns to our business objective because, we know, that offering the most competitive alternative should, by rights, increase sales. But how do we achieve this? Here’s our problem, and this is where our product goals come in. As a product, the eBay shop team may decide to set three goals for the first six months of the year for their product, each aligning back to the product statement; increase seller reviews from 4.0 to 4.5 stars<\/strong>, r<\/strong>educe turnaround from order placement to delivery by a day<\/b>,\u00a0and reduce bounce rates by 40%<\/strong>.<\/p>\n<\/p>\n
Each of these goals can be tied back to a hypothesis, which in turn can be tied back to the product statement; we want to increase ratings, for example, because we believe that the more trustworthy our buyers perceive us to be, the more likely they are to consider us a viable alternative to buying a second hand pair of shoes, and therefore the more likely they are to complete a purchase. Now we have our product goals, and from here we can begin to deconstruct these into smaller, more manageable problems to solve – our problem roadmap. For example, we might decide that a problem to solve might be that a high proportion of buyers don’t leave any feedback at all, so finding a solution to that issue may become the first problem on our team’s problem roadmap.<\/p>\n
From there, the team can take this problem and work out some proposed solutions; maybe they decide that the first possible solution might be to send an automated email asking for feedback after a product has been delivered. This can be implemented, and then measured, in relation to the KPIs defined for the problem roadmap, which in turn can be measured against the short-term goals, which can in turn be measured against the product statement, and onwards until we hit the top of the problem chain. When this model works, everything being built should be traceable back to the top-level objective, and every member of the team should be able to articulate why they’re doing what they’re doing.<\/p>\n
On the flipside of this, if the team is simply given the task of increasing sales by 20%, the fact that this problem hasn’t been broken down to a manageable level can leave the team trying to climb mount Everest; the likelihood of implementing a single feature that solves this problem instantaneously is slim to nil.<\/p>\n
Giant problem-bear totally ate your solution.<\/p><\/div><\/p>\n
This can also cause issues in terms of the actual implementation; if a developer is given a remit that isn’t transparent in terms of its objectives, it is nigh on impossible to articulate where to draw the line in terms of engineering effort; without context of where your task fits within the wider picture, there’s no basis by which to prioritise the appropriateness of your solution – or indeed to ensure that what you build is a suitable platform on which to build whatever is coming next.<\/span><\/p>\nBeing able to review the problem you’re trying to solve in the context of the business within which you are working is crucial, and there are some practical methods for checking in on the goals your team has been set to ensure they’re the right size and shape for your team to try and solve ( I know: IMF would hate this). One method is to apply the INVEST <\/a>principles, commonly applied to stories, to your problem:<\/p>\n\n- I – Independent<\/strong>; is the problem sufficiently independent in that a solution can be worked on without the need to depend on other areas of the business?<\/li>\n
- N – Negotiable<\/strong>; is the problem sufficiently broad so that a series of potential solutions could be arrived at?<\/li>\n
- V – Valuable<\/strong>; does a solution to the problem offer a value that can be articulated concisely, which aligns to the wider business objectives?<\/li>\n
- E – Estimable<\/strong>: can any potential solution to the problem be estimated (with some degree of certainty) in terms of the effort required to achieve it?<\/li>\n
- S – Small<\/strong>; is the problem small enough that the team can arrive at a solution they have a reasonable degree of certainty might solve it?<\/li>\n
- T – Testable<\/strong>: Once we’ve applied a solution, can we test the effectiveness of that solution in a practical fashion?<\/li>\n<\/ul>\n
Being able to revisit the problems you are being asked to solve, and being able to gauge that they’re suitable to tackle is massively important, and something like INVEST can offer some tangible methods by which to do that.<\/p>\n
I have it on good authority that Jack Reacher uses INVEST to work out if he should tackle a problem or not in the first place. Ethan Hunt? Well, he’s got wicked-sick sunglasses, for sure; but he’s biting off more than any reasonable product team should chew.<\/p>\n
Sorry not sorry.<\/p><\/div><\/p><\/blockquote>\n","protected":false},"excerpt":{"rendered":"
Jack Reacher is pretty fabulous. If anyone reading this has read a Jack Reacher novel, or watched one of the Jack Reacher films, you’ll be aware of the awesomeness of Jack Reacher. Jack Reacher. He’s mainly awesome, in my opinion, because of things like this: See? The man is built like a tank, has the […]<\/p>\n","protected":false},"author":4,"featured_media":685,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[6,7],"tags":[],"_links":{"self":[{"href":"http:\/\/scrummable.com\/wp-json\/wp\/v2\/posts\/672"}],"collection":[{"href":"http:\/\/scrummable.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/scrummable.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/scrummable.com\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"http:\/\/scrummable.com\/wp-json\/wp\/v2\/comments?post=672"}],"version-history":[{"count":4,"href":"http:\/\/scrummable.com\/wp-json\/wp\/v2\/posts\/672\/revisions"}],"predecessor-version":[{"id":732,"href":"http:\/\/scrummable.com\/wp-json\/wp\/v2\/posts\/672\/revisions\/732"}],"wp:featuredmedia":[{"embeddable":true,"href":"http:\/\/scrummable.com\/wp-json\/wp\/v2\/media\/685"}],"wp:attachment":[{"href":"http:\/\/scrummable.com\/wp-json\/wp\/v2\/media?parent=672"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/scrummable.com\/wp-json\/wp\/v2\/categories?post=672"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/scrummable.com\/wp-json\/wp\/v2\/tags?post=672"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}