Relevance is KING! ♔
It could be of paramount importance for product teams to build a shared understanding, collaborating effectively more so over async work. To define, maintain & build on the relevance is the ultimatum.
Complexity could be Infinite
The reputation of something that’s a domain, language, craft, artform being very complex gets submerged into broader markets spreading out quick and wide like wildfire goes to any lengths over suppressing all those positive voices that rise up and speak against it. And teams / members could now find themselves just a stone-throw away from severe complexity, thanks only to the singular, self-centric, ego-filled individualistic behaviors of that one specific person / a certain set of people who are bound to carry their own inhibitions and may be dying for constant attention and approval of their peers.
Nonetheless, complexity is already prevalent to a given extent within domains and over their intricate nuances. The last thing one should be gunning for is inducing complexity by way of unnecessary processes / workflows / methodologies / hierarchies et. al.
Complexity Induced Over Preconceived Notions
For instance: Calculus!
It may have a reputation of being difficult as it has been for 2 decades since we waded through it during our stint with Math / Applied Math as opposed to OR (Operations Research) & Fourier Transforms enjoying an eternal reputation of being tough.
Here is a VENN depicting the emotions people of a certain sample space towards the subject of CALCULUS.
But, having said all of that, there is that 0.01% of the sample space sandwiched right in between the sweet spot of the Venn who think it could be EASY. The reason they find it easy is because they are doing something right which others feel is impossible.
The most common reason for something perceived as complex is the lack of basic understanding. And, of course there could undeniably be other influencing factors like how people rely on hearsay and derive their notions out of it making it seem like the complexity is truly infinite when the reality isn’t in any way close to that, in fact the total opposite.
Deliberately Induced Complexity
For instance: Consider this Flowchart here.
Though the intent behind this chart originally may have been humor, consider this.
To answer the question:
“Do we need a flowchart or Not?”
→ Would you feel it necessary to build a whole flowchart?
The most sane answer obviously is:
No, no way. Not a chance.
I have no trouble in admitting to the fact that the underlying single step flowchart which actually is a miniature subset of the previous one would serve the same purpose.
NOTE: Though the whole example of the flowchart up here was chosen & depicted over a lighter note, beware of some traits and culture of teams who believe in making things deliberately complex and to quote what they think and go by “just to make it look more attractive”. When that happens, whether it serves the intended purpose or not could become a secondary question. It could be off-putting for many of your own team members which may be “THE precursor” leading to one too many major disconnects. That’s a chink in the armor, an antipattern which may need some very strong discouragement right at the beginning.
Building Relevance – An Understated PM Superpower
PM is already very complex because of multiple nuances it carries, the multiple interfaces the role has with teams both internal and external, not to mention the pragmatic angle of the job that requires one operating in those positions to assess everything from a very practical standpoint.
In doing so, one is required to be very strong in communication, and I am not even remotely referring to the English language here when I say that preciseness, succinctness help and go a long way in building relevance.
Let’s capture the essence of communication of ideas leading towards building that all-important shared understanding as relevant over each of the steps of a PM’s regular workflow.
1. Ideation
At the helm of every product process time is allotted to figure out tons of stuff that is meant to lend direction over what is to be done to achieve / put the teams in the right path over it. Teams could very easily to lose track of what is to be done if the Central Idea is not cemented very strongly or even worse would be to get a clarity of only half the thing pushing the other part into a black hole of conviction over subjecting it to a “fill in the blanks” / “fill whatever you deem relevant here” kind of a scenario.
Some frameworks that could help you build that crucial relevance here are:
1.1 “Main Job To Be Done” of JTBD Framework – By Tony Ulwick
JTBD requires you to start by defining the Main Job To Be Done whilst accentuating the motivations & pain areas over capturing the functional & emotional aspects and also listing out the other Related Jobs To Be Done.
1.2 Product Ideation Framework
This one works when you’re trying to build quick clarity over constructing a detailed picture of the problem domain over measuring 3 things chiefly Internal strengths, Market weakness & Adjacent possibilities. In doing so it also aims to capture & help list out findings of those elements that lead to Friction, Passion & the Technology.
2. Discovery
The single large tangible outcome usually all product teams watch out for is the culmination of the Ideation cycle that could lead to tons of various facts from the field that then ought to be represented and carried over to the Discovery phase over delving a lot deeper in an aim to find more insight which could further assist in building a shared understanding of the problem.
Some frameworks that you ought to know and use are:
2.1 User Story Mapping
User Story Mapping helps to understand and capture the interactions over steps the users take to get their job done as a part of their regular workflow. It makes effective use of sketches to outline those interactions. In this parlance the 3 C’s that ought to matter are Card, Conversation & Confirmation.
2.2 Empathy Maps
It’s a good step and a great practice to capture the emotions of the users over their Pains, Gains whilst also getting a step deeper to drilldown over understanding the same verbatim over things they Say & Do, See, Hear, Think & Feel.
3. Strategy
Once the discovery has been successful it has to transition into building an effective strategy over defining the future course of the product in spelling out the direction to take and it is also a step that product teams pin on for some kind of clarity from a state of seeing (n) possibilities and lack of direction which route to take.
3.1 JTBD (Jobs To Be Done) Template by Product School on Miro Verse
There is a ton of information that could be captured here over this template apart from just defining the Central JTBD it could also be used to capture information that could substantiate quoting the required insight over Customer’s interviews, interactions, responses & insights.
3.2 Business Case Canvas by Alex Osterwalder
If you want to accentuate your strategy further by figuring out all things that ought to matter to your product over binding how it caters to your Customers via a Product Offering / Value Proposition whilst also figuring out things like Costs & Revenue cycles the business case canvas / business model canvas is a must have in your amour.
4. Roadmaps
Further extending the Strategy which loosely defined the “what” that is to be done, the roadmap then tries to build more clarity over defining the high-level EPICs which could be thought of as chapter headings in a story book. They just define the features via suitable names without getting too much into the details of those individual features / specifications / user stories.
4.1 Now, Next Later
A definition of what is to be done NOW, what follows NEXT and what’s going to come much LATER ought to be the most natural course of building a Roadmap. When a roadmap helps put the strategy into perspective by building a bit more of that clarity for all the teams involved, they still don’t cover the minute details of the “What” of the build cycle and neither do they carry any timelines on them.
5. Build
Prior to starting off this and somewhere after building strategy & roadmaps or in between the EPICs are broken down further into defining User Stories and each of them have a purpose and an acceptance criterion – Definition of Done. The build phase lends some tangibility to the product when it begins to take shape here slowly over silos of iterative development.
NOTE: Many of these methodologies mentioned hereunder and widely used today are known to have originated from Agile itself.
Agile Manifesto
Agile is more or less a de facto standard today given the product development space. A methodology that aims to drastically reduce the time taken over the build cycle which preaches the objective of building a small but fully functioning parts of the product incrementally in silos enforcing all teams to collaborate efficiently over a given set of requirements they plan to address targeting a set of user stories in each iteration - so as to have a small meaningful portion of the working product at the end of each silo.
5.1 Agile Scrum
Scrum is one of the primary agile methods. It aims to boost team productivity, velocity, optimize product value by relying on regular feedback from the end users. It promotes the Agile Manifesto values: more collaboration with the client, overcoming the fear of change, putting interaction with people at the center of any software project management, and focusing on delivering operational software.
5.2 Agile Kanban
Kanban is another popular framework used to implement agile & DevOps software development. Foremost, it requires a very mature team, real-time communication of capacity, full transparency of work. Work items are represented visually over various vertical swim-lanes each standing for the statuses as relevant to the teams & control is enforced via WIP (Work In Progress) limit that tends to cap the no. of work items allowed in each of those swim-lanes at any given point in time allowing members the freedom to collaborate & concentrate on minimalistic deliverables / work items over each silo.
5.3 TDD (Test Driven Development)
Test Driven Development was originally introduced as a part of the extreme programming (XP) manifesto. It preaches test-first development where developer writes a fully-automated test case before writing any code. It is a practice of writing a failing test before doing up the coding part, a feature which is then refined until it passes the unit test.
5.4 XP (eXtreme Programming)
eXtreme Programming (XP) is an Agile methodology which takes software development to the extreme by combining best practices while focusing on extreme quality and extreme responsiveness to changing customer requirements. Although eXtreme Programming (XP) can be used as a standalone Agile methodology for very seasoned teams, it truly brings great value when used to expand Scrum or other Agile methodologies.
5.5 Rapid Prototyping
Rapid prototyping is an agile strategy used throughout the product development process with multiple iterations generated during a short period based on user feedback and analysis. With this approach, 3-dimensional prototypes of a product or feature are created and tested to optimize characteristics like shape, size, and overall usability.