WordCamp Asia 2026 Nabin Jaiswal Stop Guessing, Start Building

WordCamp Asia 2026: Nabin Jaiswal "Stop Guessing, Start Building" ![rw-book-cover](https://img.youtube.com/vi/AVgcMEPjvko/maxresdefault.jpg) 🔗 **Source:** [WordCamp Asia 2026: Nabin Jaiswal "Stop Guessing, Start Building"](https://www.youtube.com/watch?v=AVgcMEPjvko) > [!note]+ Document Notes > tags: #product-management #wordpress #customer-feedback #team-communication #product-development > author: Nabin Jaiswal > source: WordCamp Asia 2026 > reference: https://www.youtube.com/watch?v=AVgcMEPjvko > date created: 2024-12-19 10:30 > > # 🏷️ Title: Stop Guessing, Start Building: A Product Management Framework for WordPress Teams >  ## 🧰 Action Inbox - [H1] Establish dedicated product team role — prevent building without purpose #product-management - [H2] Implement Kano analysis for feature prioritization — organize thousands of backlogged issues #prioritization - [H3] Structure GitHub issue reporting with clear templates — eliminate communication gaps #workflow ## 🧭 Table of Contents - [[#📝 Summary]] - [[#📖 Main Content]] - [[#🗒️ Notes]] - [[#📚 References]] - [[#🗣️ Paraphrase]] - [[#📰 Newsletter]] - [[#✅ Action Items]] - [[#🧪 Hypotheses]] - [[#📊 Methodology]] - [[#❓ Questions]] - [[#🔮 Future Research]] - [[#💡 Implications]] - [[#🧠 Learning Styles Assessment]] - [[#📊 Accessibility Assessment]] - [[#🌍 DEIB Assessment]] - [[#✅ Logical Validity]] - [[#🛡️ DARVO Analysis]] - [[#🎯 Conclusion]] ### 🔗 References - [Kano Analysis Framework](https://en.wikipedia.org/wiki/Kano_model) - [Scrum Inc. Product Owner Course](https://www.scrum.inc/) ## 📝 Summary - **What happened**: Nabin Jaiswal from CodeWing Solutions shared how his team transformed from building features in endless loops to implementing systematic product management practices for WordPress products - **Why it matters**: Many WordPress businesses struggle with feature prioritization, team communication gaps, and building without clear purpose - leading to customer frustration and wasted development resources - **Key stakeholders**: Product owners, developers, support teams, and WordPress business owners in travel tech and plugin/theme development - **Risks and tradeoffs**: Implementing structured processes requires dedicated resources and cultural change, but prevents building features customers don't notice or need - **Bottom line**: Systematic product management with dedicated roles, clear communication workflows, and frameworks like Kano analysis transforms chaotic development into customer-focused outcomes ## 📖 Main Content CodeWing Solutions faced common WordPress product development challenges: building features without clear purpose, no prioritization system, scattered customer feedback across multiple channels, and communication gaps between product and engineering teams. These issues led to delayed deliveries, buggy releases, and frustrated customers. The solution involved five key changes: establishing a dedicated product team, restructuring GitHub issue reporting, implementing ownership and accountability frameworks, using Kano analysis for prioritization, and improving release communication. The Kano analysis framework categorizes features as must-have (fix immediately), performance (customers happy when included), excitement (delighters that can be delayed), and indifferent (defer or hold). The team implemented automated Slack notifications for GitHub activity, created dedicated channels for urgent issues, and established clear roles: support captures and reports issues, product team analyzes and writes acceptance criteria, engineering implements based on clear requirements. They also integrated AI code review with Claude while maintaining developer oversight and final decision authority. ## 🗒️ Notes #### ⏱️ [00:00](https://youtu.be/AVgcMEPjvko?t=0) — [H1] Building features in endless loops without purpose - Key idea: Teams ship features regularly but don't focus on outcomes that solve customer pain points - Evidence: "We had been building features and shipping them regularly. On surface, everything looks fine, but under the hood, we're not actually focused on the outcomes" #### ⏱️ [02:15](https://youtu.be/AVgcMEPjvko?t=135) — [H2] No prioritization system creates urgency chaos - Key idea: Without prioritization frameworks, every customer request feels urgent leading to reactive development - Evidence: "Everything that the customer reported felt urgent and we were in a rush like hey we should be building this feature" #### ⏱️ [03:30](https://youtu.be/AVgcMEPjvko?t=210) — [H3] Scattered feedback across multiple channels - Key idea: Customer feedback through GitHub, email, chat, and Facebook creates fragmented understanding - Evidence: "All were scattered there wasn't a single point connecting those things" #### ⏱️ [04:45](https://youtu.be/AVgcMEPjvko?t=285) — [H2] Communication gap between product and engineering teams - Key idea: Product vision misalignment with engineering implementation causes delays and bugs - Evidence: "The product team would envision the product needs to be built in a certain way and the engineering team would build based on their understanding" #### ⏱️ [07:30](https://youtu.be/AVgcMEPjvko?t=450) — [H1] Dedicated product team essential for focus - Key idea: Product teams think about products full-time and provide clarity on why features are built - Evidence: "If you don't have any product team, people will be building the product without knowing why they're actually building those products" #### ⏱️ [10:15](https://youtu.be/AVgcMEPjvko?t=615) — [H2] Structured GitHub issue reporting improves clarity - Key idea: Template-based issue reporting with proper titles, labels, descriptions, and customer info creates single source of truth - Evidence: "Every issue starts with the proper title. We tag every issue with the right label. Every issue has a clear description" #### ⏱️ [12:00](https://youtu.be/AVgcMEPjvko?t=720) — [H3] Slack automation enables real-time GitHub notifications - Key idea: Automated notifications when tagged in GitHub prevent delays from email checking - Evidence: "We built an automation whenever somebody tags in GitHub they get a realtime notification in Slack" #### ⏱️ [14:20](https://youtu.be/AVgcMEPjvko?t=860) — [H2] Clear role definition prevents ownership confusion - Key idea: Defined responsibilities for support, product, and engineering teams eliminate role ambiguity - Evidence: "Support team communicates with customers, product team analyzes reported issues, engineering team implements based on written acceptance criteria" #### ⏱️ [16:45](https://youtu.be/AVgcMEPjvko?t=1005) — [H1] Define non-negotiables for critical user flows - Key idea: Identify core features that directly impact customer experience for immediate prioritization - Evidence: "Non-negotiables are features that will directly impact our customers on how they are using those features" #### ⏱️ [18:30](https://youtu.be/AVgcMEPjvko?t=1110) — [H1] Kano analysis framework for feature prioritization - Key idea: Categorize requests as must-have, performance, excitement, or indifferent for systematic prioritization - Evidence: "Must have - if you don't have the customers will get frustrated. Performance - customers are going to be happy. Excitement - customers will be happy but not expecting" #### ⏱️ [21:15](https://youtu.be/AVgcMEPjvko?t=1275) — [H2] Customer communication prevents feature invisibility - Key idea: Proactive communication about feature development and releases ensures customer awareness - Evidence: "We are building the features. The customers would reach out to us and say that hey I'm looking for this feature and our team would be like hey we have already built the features" #### ⏱️ [23:45](https://youtu.be/AVgcMEPjvko?t=1425) — [H3] Community feedback shapes product development - Key idea: Facebook community with 2300+ customers provides valuable feedback before and after feature development - Evidence: "Before building any features we build any kind of design or prototype we share in the community and they share us with the feedback" #### ⏱️ [26:30](https://youtu.be/AVgcMEPjvko?t=1590) — [H3] AI code review with developer oversight - Key idea: Claude AI reviews code but developers must acknowledge disagreements with reasoning - Evidence: "We don't merge any issues any PR until the developer and the Claude code are in sync with the necessary comments" #### ⏱️ [29:00](https://youtu.be/AVgcMEPjvko?t=1740) — [H2] WordPress.org as distribution gem for products - Key idea: WordPress repository provides community exposure and feedback for product improvement - Evidence: "WordPress.org is like a gem for distribution. You can always connect with the other team members and ask for the feedbacks" ## 📚 References - [Kano Analysis Framework](https://en.wikipedia.org/wiki/Kano_model) - [Scrum Inc. Product Owner Course](https://www.scrum.inc/) - [CodeWing Solutions](https://codewing.com/) ## 🗣️ Paraphrase - Successful WordPress product development requires dedicated product teams who understand why features are built, not just what to build - Structured communication workflows with clear issue reporting, automated notifications, and defined team roles eliminate confusion and delays - Prioritization frameworks like Kano analysis help categorize thousands of feature requests into actionable categories based on customer impact ## 📰 Newsletter **Stop Building Features Your Customers Won't Notice** WordPress product teams often fall into the "endless feature loop" - building and shipping without clear purpose or customer validation. Nabin Jaiswal from CodeWing Solutions shared how implementing systematic product management transformed their travel tech WordPress products. **Key takeaway**: Establish a dedicated product team member whose job is to understand *why* each feature should be built, not just *what* to build. **Quick wins for your team**: - Structure GitHub issues with clear templates (problem, reproduction steps, expected behavior) - Use Kano analysis to prioritize your feature backlog (must-have vs. nice-to-have) - Set up automated Slack notifications for GitHub activity - Define clear roles: who captures issues, who analyzes them, who builds them The result? CodeWing reduced buggy releases, eliminated communication gaps, and built features customers actually notice and appreciate. Resources: [Learn WordPress](https://learn.wordpress.org/), [Developer Docs](https://developer.wordpress.org/), [WP-CLI](https://wp-cli.org/) ## ✅ Action Items #### DevRel - Developer experience: Create GitHub issue templates that include customer context and acceptance criteria - Education: Workshop on Kano analysis for WordPress product teams prioritization - Community management: Establish Facebook/Slack communities for customer feedback collection #### WordPress - Core Program Team: Apply structured communication workflows for cross-team coordination - Community: Develop mentorship programs for WordPress product management best practices - Documentation: Create guides for systematic feature prioritization in WordPress products - Plugins: Review throughput improvements through structured issue reporting #### Community - Maintainers: Implement governance templates for product decision-making processes - Contributors: Onboarding programs that explain why features are built, not just how ## 🧪 Hypotheses - WordPress teams with dedicated product roles ship fewer buggy features than teams where developers make product decisions - Structured GitHub issue templates reduce feature development time by 30-40% compared to unstructured reporting - Teams using prioritization frameworks like Kano analysis have higher customer satisfaction scores - Proactive release communication increases feature adoption rates among existing customers ### 📊 Methodology - Survey WordPress product teams on communication workflows and bug rates - A/B test GitHub issue templates measuring development cycle time - Implement Kano analysis with control groups to measure customer satisfaction ### ❓ Questions - How do different WordPress product types (plugins vs themes vs SaaS) need different product management approaches? - What metrics best indicate when a WordPress team needs dedicated product management? - How can small WordPress agencies implement these practices without hiring dedicated product staff? ### 🔮 Future Research - Integration of AI tools in WordPress product management workflows - Cross-team communication patterns in distributed WordPress development - Customer feedback integration across WordPress.org reviews, GitHub, and social channels ### 💡 Implications - Practice: WordPress teams need structured processes for feature prioritization and customer communication - Education: Product management skills should be included in WordPress developer training - Community: WordPress.org could benefit from better feedback integration tools for product teams ### 🧠 Learning Styles Assessment Reading level estimate: 9th grade (Flesch-Kincaid) #### 👀 Visual learners - Present: Screenshots of GitHub issue templates, Kano analysis categorization matrix - Improve: Workflow diagrams, team communication flowcharts, priority visualization tools #### 🔊 Aural learners - Present: Video presentation with clear explanations and examples - Improve: Audio summary of key frameworks, podcast discussion on implementation #### 🗣️ Verbal learners - Present: Clear definitions of product management terms, framework explanations - Improve: Glossary of product management terminology for WordPress context #### 🧩 Kinesthetic learners - Present: Step-by-step GitHub template implementation, hands-on Kano analysis exercise - Improve: Interactive prioritization workshops, team role-playing exercises #### 🧠 Logical learners - Present: Clear cause-and-effect relationships between processes and outcomes - Improve: Metrics dashboard examples, ROI calculations for product management investment #### 🧑‍🤝‍🧑 Social learners - Present: Team-based implementation examples, community feedback integration - Improve: Peer learning groups, cross-team collaboration exercises #### 🧘‍♀️ Solitary learners - Present: Individual reflection on current team practices - Improve: Self-assessment checklist for product management maturity #### 🌿 Naturalistic learners - Present: Organic growth of customer communities, ecosystem thinking - Improve: Product lifecycle analogies, sustainable development practices ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Clear heading structure, descriptive timestamps - Improve: Alt text for workflow screenshots, ARIA labels for interactive elements #### Keyboard navigation - Present: Logical tab order through content sections - Improve: Skip links to main sections, keyboard shortcuts for video controls #### Contrast and readability - Present: High contrast text, readable font sizes - Improve: Ensure 4.5:1 contrast ratio for all text elements #### Media and captions - Present: Video with clear audio, transcript available - Improve: Detailed captions including speaker identification and technical terms ### 🌍 DEIB Assessment #### Cultural breadth - Present: Travel tech examples relevant globally - Improve: Product management examples from diverse cultural contexts #### Inclusive language - Present: Gender-neutral team references, clear technical definitions - Improve: Avoid idioms like "gem" that may not translate across cultures #### Neurodiversity support - Present: Structured presentation with clear sections - Improve: Consistent formatting, predictable information hierarchy #### Representation - Present: Focus on systematic processes rather than individual heroics - Improve: Include diverse team composition examples ### ✅ Logical Validity #### Strong reasoning - Deductive strength: Clear cause-effect relationships between structured processes and improved outcomes - Inductive strength: Specific examples from CodeWing Solutions generalized to broader WordPress community - Causal reasoning: Direct links between communication gaps and product development problems #### Fallacies - Survivorship bias: Only shares success story without acknowledging failed attempts or alternative approaches - Hasty generalization: Assumes all WordPress teams face identical challenges to CodeWing Solutions #### Tone of voice - Overall tone: Helpful and practical, sharing lessons learned without being prescriptive ### 🛡️ DARVO Analysis - No evidence of DARVO patterns; presenter acknowledges team's past mistakes and shares solutions constructively ## 🎯 Conclusion Systematic product management transforms WordPress development from reactive feature-building to customer-focused outcomes. The key is establishing dedicated product roles, structured communication workflows, and prioritization frameworks like Kano analysis. Teams implementing these practices report fewer bugs, faster development cycles, and higher customer satisfaction. For WordPress businesses struggling with endless feature backlogs and communication gaps, these proven frameworks offer a clear path to more intentional, effective product development. ## 🧱 Refactor Appendix ### 📚 Literature Split Pad ### [H1] Dedicated product teams prevent purposeless development > [!quote] Stop Guessing, Start Building by [[Nabin Jaiswal]] via [[WordCamp Asia]]. Published 2024. Accessed 2024-12-19. > "If you don't have any product team, people will be building the product without knowing why they're actually building those products." Essential for WordPress teams to have someone thinking about product strategy full-time rather than --- ## Full Transcript [00:06] Good morning everybody. I'm excited to [00:09] see you all here. Before we dive into, [00:11] can you please take a moment to raise [00:13] your hands if anyone from the audience [00:17] uh owns a business, is a product owner [00:19] or even a developer? Could I see a few [00:22] hand raises? Oh, I can see plenty of [00:24] hand raises. [00:26] So today [00:29] I'm going to share something that comes [00:32] from my experience that I have learned [00:34] as a team. I'm Navin Jal co-founder of [00:38] codewing solutions. We build WordPress [00:40] themes and products and we primarily [00:43] focus in travel tech industry. [00:47] Now before we dive into the actual [00:51] presentations, these are my actual [00:53] learnings that we had learned as a team [00:57] and honestly I believe that I wish [01:00] somebody had told me this earlier. [01:07] Now let me share something that we had [01:09] been doing in the past. [01:12] We had been building features and [01:14] sipping them regularly. On surface, [01:17] everything looks fine, but under the [01:20] hood, we're not actually focused on the [01:24] outcomes that would actually solve the [01:26] customer's painoint. [01:28] So, we decided we need to fix that. And [01:34] the next thing we did was [01:37] we [01:39] went through our system and realized [01:41] that we're building the future in an [01:43] endless loop. Whatever features came, we [01:46] start building. We were building [01:49] unintentionally. [01:51] And when we look dive deeper into it, we [01:54] realized that there were so many [01:56] problems that needed to fix. [01:59] One of the major issue was that we had [02:04] no prioritization system. [02:06] Everything that the customer report felt [02:09] urgent and we were in a r like hey we [02:11] should be building this feature. Let's [02:13] build this feature and it was always an [02:16] endless loop. [02:18] The next thing was [02:22] the next thing was [02:25] all the customers issues were reported [02:28] in the GitHub. All the feature requests [02:31] were there. All the customers pain point [02:32] were there and it were get just dumped [02:36] there and it used to be in that GitHub [02:40] for many years. There was no system like [02:43] how we should prioritize or when should [02:45] we start building those things. This was [02:47] the actual problem. [02:51] The next problem that we identify was we [02:56] communicate with our customers over the [02:58] emails chat and even through the [03:00] Facebook they were sharing their [03:01] feedbacks that pinpoint over those [03:03] mediums and since all were scattered [03:07] there wasn't a single point connecting [03:09] those things. somebody uh since we have [03:11] different team members, every team [03:13] members communicate with different [03:14] customers. So there wasn't anything that [03:17] would tie up the same customers [03:19] pinpoint. [03:21] The next thing that we realized was [03:23] there was a huge communication gap [03:25] between the product team and the [03:27] engineering team. The product team would [03:30] envision the product needs to be built [03:32] in a certain way and the engineering [03:34] team would build based on their [03:36] understanding. [03:38] As a result, it often lead into delays [03:42] of the deliveries or the features that [03:44] we are working on. And when we see the [03:46] feature, it often included box and [03:50] sometimes we have to roll back and [03:54] ultimately the customers were [03:56] frustrated. We're losing customers and [03:58] these were the pain points and the [04:01] problems that existed in our working [04:03] model. [04:06] Now I did a course in September 2024 [04:11] is called a register product owner by [04:13] scrum inc. And in the course I didn't [04:16] learn something that was completely new [04:18] but I got to know about some of the [04:20] frameworks that helped me open up many [04:23] possibilities that I can explore within [04:25] my organization. [04:28] And today my talk is all about those [04:31] things. what are the changes that we did [04:33] and how it has helped us to grow our [04:36] product. [04:39] So without any further delay, let's get [04:42] this started. Here are the things that [04:43] I'll be covering in today's [04:45] presentation. [04:48] So [04:50] why every product [04:53] needs a dedicated product team? Then [04:55] we'll talk about what are the things we [04:57] did to fix the communication gap between [04:59] our team. Then we all I'll also share [05:03] about how we are enforcing or [05:06] implementing ownership and [05:07] accountability among our team as well as [05:11] solve the major things that we're facing [05:13] that is prioritizing the issues the [05:16] feature requests by the customers and [05:19] finally we'll talk about how we are [05:21] communicating the releases that we are [05:23] doing. So are you all excited? [05:28] Now let's talk about the first thing. I [05:33] see a few hand raises. Uh here are some [05:36] product owners. So does any of you have [05:39] a dedicated product team in your [05:42] company? Can I see any hand raises? [05:45] Okay, I see one, two, three. Okay, [05:48] great. Four. Okay, great. Now [05:54] I also lead the product. So I I am [05:57] involved in me um many products. So my [06:00] availability is limited and this is [06:04] something that my mentor told me if you [06:06] really want to grow your business you [06:09] should work on the business not in the [06:11] business. [06:13] This is a deep thought. I want you to [06:15] look into that what this really means. [06:18] So since my availability was limited, I [06:21] was not able to provide the detail [06:23] requirement, the clarity my team needed [06:25] to work on those features. [06:28] And we decided let's fix that [06:32] and we hire a dedicated product [06:35] associate whose responsibility was to [06:38] think about the product all the time. If [06:41] we are building any features, he or she [06:44] is responsible to let the team know why [06:47] we are building this feature. [06:50] If you don't have any product team, the [06:52] problem that you'll [06:54] face is that people will be building the [06:56] product without knowing why they're [06:58] actually building those products. So [06:59] this is the first thing that we did. We [07:01] hired a dedicated product team who will [07:04] do the different responsibility related [07:06] to the product. And in our organizations [07:09] the product team consists of me as a [07:11] product owner and a product associate. [07:14] We do an occasional meeting where we [07:16] discuss about the things that we are [07:18] going to build over the time [07:23] depending on what are the things how [07:25] your organization is structured. The [07:27] roles and responsibility of product [07:29] owner or product team might differ [07:32] differently. In our organizations there [07:34] are different things that we involve our [07:36] product team. The first thing they do is [07:38] analyze the issues. [07:40] Every week lots of issues get uh [07:43] recorded in the GitHub and the first [07:46] thing the product team does is they go [07:49] through the issues understand the issues [07:52] and then plan when to build this [07:54] feature. [07:57] The next thing is they sit with the [07:59] engineering and support team to [08:01] understand if anything is unclear. If [08:04] there is any kind of urgency, the [08:05] support team communicates to that [08:07] product team and the product team can [08:09] escalate with the product owner and then [08:11] decide when to build those features. [08:16] The next thing just like I mentions we [08:18] sit on a a regular basis to analyze what [08:22] are the different issues that are [08:24] reported or the feature request why we [08:26] should be building the feature. If [08:28] anything is unclear to my product [08:29] associate I provide the necessary [08:31] details or provide the necessary [08:32] guidance how they can look into [08:36] and the next and most important thing is [08:39] that the product team is also [08:42] responsible for the customer outreach. [08:44] I'll share in detail how we are doing [08:46] customer rees later in the presentation. [08:53] Now the another thing that you might [08:56] also have face in your organizations is [08:59] the communication gap between your team [09:02] and this is very common. So we had a [09:06] team of a product team usually consist [09:08] of the support engineering and the uh uh [09:12] support and product team. All were [09:14] working together. They were working hard [09:16] but the directions were not always the [09:19] same. And this is the thing we needed to [09:21] fix first. [09:24] So what are the things that we did? The [09:26] first thing we did was structure how we [09:30] used to report our GitHub. So the [09:32] support team reports the GitHub issues. [09:36] Let me share how we used to report the [09:38] GitHub issue in the past. [09:41] So as you can see here, it just has a [09:43] title and what the problem is the [09:46] screenshot and the uh ticket link. [09:51] Okay. Now this might be fine for some [09:54] but the product team had a hard time [09:56] understanding what the issue is, what [09:58] the customers is actually looking for. [10:02] So this is the first thing we fixed. So [10:04] we introduce [10:05] how [10:07] so we introduce how we should report any [10:10] issues in GitHub. Every issue starts [10:13] with the proper title. We tag every [10:17] issue with the right label. [10:20] Every issue has a clear descriptions [10:22] what the issue is about. How anyone can [10:25] reproduce the issues and what is the [10:28] expected behavior? what the customer is [10:30] expecting to and finally what is [10:33] actually happening. We also record the [10:35] customer informations. You'll know why [10:38] we are recording this informations. [10:44] We use GitHub for our project [10:46] management. We try different tools. I [10:48] believe GitHub just make it so simple. [10:51] So this is the whole communications [10:54] happens in the GitHub. any issues [10:56] anything any decision related to the [10:59] issue is logged in the GitHub as a [11:02] single source of truth for us [11:07] and this allow us to reflect back on any [11:10] of the decision that we had made in the [11:12] past. [11:16] Now whenever somebody tags since I [11:18] mentioned we use GitHub for [11:21] communication. So whenever somebody tags [11:23] we get an email and our team is busy [11:26] doing their own task. So they won't be [11:28] able to check the SL uh their emails all [11:31] the time. So we need a solution. So we [11:33] build an Nain automations whenever [11:36] somebody tags in GitHub they get a [11:38] realtime notification in Slack. As a [11:42] result, if they need to take an actions [11:44] like a product team added certain [11:47] acceptance criteria, the engineering [11:49] team gets instant notifications. If they [11:53] think that certain things is missing, [11:54] they can just communicate to the product [11:58] team. This makes us easier. Instead of [12:00] waiting for certain time, the things [12:03] moves faster. [12:08] And [12:09] the next thing we did was created a [12:11] dedicated channel for support and [12:14] product team. Just like I mentions every [12:16] week we have lots of issues reported and [12:20] if we go through let's suppose we have [12:22] 50 issues reported or feature request or [12:24] customers pinpoint reported the major [12:27] the urgent issues get lost. So we [12:29] created a dedicated channel where the [12:31] support team communicates the urgent [12:34] issues that needs to be escalated right [12:36] away. [12:37] As a result, the product team can look [12:39] into like, hey, these are the things we [12:41] need to do and they can start working on [12:43] the acceptance criteria or even the [12:45] planning or the research. Trust me, this [12:48] process has helped us to make our [12:50] customers a lot more happier. They [12:52] report an issue. We think this is an [12:53] urgent. We fix this issues and we [12:56] immediately inform the customers that [12:57] hey, we have fixed the issue. Just try [13:00] it out. [13:04] Now the next thing was developing [13:08] ownership and accountability among our [13:10] team. [13:12] When you have different teams working [13:15] together and the roles is not clear, [13:19] nobody knows what they want. So whenever [13:21] an issue cames and if it is not clear [13:24] who is going to escalate those issues, [13:26] who is going to write the [13:27] documentations, who takes the final [13:29] call, nobody is going to act on it. So [13:32] the this is the thing that we fixed. We [13:35] decided let's segment what are the [13:38] different roles are for each of the team [13:41] members. The first thing the support [13:44] team they communicates with the [13:46] customers capture the issues and reports [13:49] the pain point in GitHub. If anything is [13:51] unclear to the product team they make [13:54] sure that they reach out to the [13:55] customers or add the necessary [13:57] information so that the product team can [13:59] understand those issues. The product [14:02] team [14:04] analyzes the reported issues, make the [14:06] necessary research and planning to [14:08] discuss with the product owner. They [14:10] also write the acceptance criteria once [14:12] the uh issue or the feature request is [14:15] clear and is ready for the development. [14:18] Now [14:20] the engineering team implements the [14:22] feature based on the uh written [14:24] acceptance criteria. They start the work [14:27] once everything is clear. So product [14:29] team help them understand why we are [14:31] building this feature, how this is going [14:33] to make an impact uh to our existing [14:36] customers and this flow has helped us to [14:40] solve the major problems that I talked [14:42] earlier which was the delay delivery and [14:44] the releases with bog. [14:51] I'm pretty sure you might have if you're [14:54] using GitHub or any other tool you might [14:56] have incorporated code review system in [14:59] your organizations any hand raises I [15:01] might see okay so few handes maybe okay [15:05] so we use clot code uh in our [15:09] organizations to acknowledge the code [15:11] review now every PR request gets [15:15] reviewed by clot code [15:18] and one of the thing that we have [15:20] implemented is code review [15:22] acknowledgement by the developers. [15:25] Claude might have a very limited uh [15:27] context about the products. They will [15:30] just review the PR based on whatever [15:32] informations they have and the [15:35] recommendations that they provide may [15:37] not be accurate all the time. Developer [15:40] has their own understandings. So [15:42] whenever claude flags any issues and the [15:46] developer doesn't agree with that they [15:49] provide a necessary reason why they are [15:51] not agreeing to it. This helps us other [15:54] team members also to understand that if [15:57] they work on the feature why certain [15:58] things was ignored and they tag the [16:01] cloud they add the region and the cloud [16:05] re-reviews the code and acknowledge [16:07] those we don't merge any issues any PR [16:12] until the developer and the cloud code [16:14] are in sync with the necessary comments [16:17] and this has helped us to solve the [16:19] major problem which was the releases [16:22] with the blog [16:25] and finally you can see like when you [16:27] provide those things we see the [16:29] checklist. [16:34] Now this is the major problem the [16:38] biggest challenge in our organizations. [16:41] Is this something that you also face? [16:45] Anyone from the audience like [16:46] prioritizing the issues when you have [16:49] okay I see few hand raises. Yes, this [16:51] has been always the biggest challenge [16:53] just like I mentions we get a lot of [16:55] feature request or b reported in GitHub [17:00] and we get lost [17:02] couple of years back we had like [17:04] thousands of issues reported just like [17:07] we were building on just whatever feel [17:09] good we building those things and we [17:11] have a backlog of thousand plus reported [17:13] issues or feature request [17:15] so we didn't knew where to start [17:19] And the first thing we did was let's [17:22] define our non-negotiable. [17:30] So what does a non-negotiable means? [17:34] It can be a different definition for you [17:36] but for us these are the features that [17:40] will directly impact our customers on [17:44] how they are using those features. [17:46] To give you an example, [17:49] we have a travel booking engine and a [17:52] typical travel booking engine has [17:55] certain flows like a customers uh [17:59] selects a package then they go to the [18:01] tour checkout then they process the [18:03] payment then there is a booking [18:05] confirmations and [18:07] the admin notifications. This is our [18:09] non- negative a complete flow that we [18:12] want to ensure this never gets uh any [18:16] issue reported regarding this one [18:18] doesn't get unnoticed. So whenever a [18:22] customer reports any issues that is [18:24] related to this one no matter what [18:25] feature we are working we immediately [18:27] prioritize this one because this is [18:29] going to win or break the trust of our [18:32] customers. [18:34] Then for prioritizing our uh different [18:37] issues that are reported we explore [18:39] through different uh mechanism or [18:42] different framework and we decided to [18:45] stick with kano analysis. Uh this is a [18:48] very good framework very easy just if [18:51] you read article it will just take you [18:53] 10 to 15 minutes to understand and you [18:55] can get started right away. So I'll just [18:58] categorize this is uh a framework by [19:02] Japanese professor [19:04] Nairoi [19:06] Kano [19:07] and he categorizes any request into [19:11] four. You can also find some five. The [19:14] first is must have. So these are the [19:16] features that if you don't have the [19:18] customers will get frustrated. So when [19:21] this gets reported fix immediately then [19:24] there are certain issues or feature [19:26] requests that if you work on those [19:28] things the customers are going to be [19:30] happy. [19:32] Prioritize those things. Then there are [19:34] also certain features that the customers [19:36] request or you think that if you build [19:38] this the customers will be happy but the [19:40] customers are not uh are not uh [19:44] expecting. So you can delay those [19:46] features and there will be also some [19:48] features that certain customers might [19:50] ask but may not be beneficial for most [19:54] of the customers or you might have [19:56] certain features in mind and you are [19:57] unsure about how it is going to impact [20:00] our your existing customers or the [20:03] customers will not even notice those [20:04] features. Simply defer them or just [20:08] prioritize or keep on hold to them. a [20:11] highly recommended framework. We use [20:12] this and this has helped us to just [20:14] prioritize very better [20:18] and this is how this is a screenshot of [20:21] our internal tool and whenever issue get [20:24] listed we use cano analysis excitement [20:27] is the delighter. So a customer requests [20:29] certain features with this and using the [20:31] filter we can know like what are the [20:32] must-h have what are the delighters what [20:35] are the performance or what are the [20:36] indifference and then we can prioritize [20:38] those things. [20:42] In addition uh in our internal tool we [20:45] also record the different customer [20:47] feedbacks. Now the bog and feature [20:49] request are something that we record in [20:52] a GitHub. But there are certain pain [20:54] points the customers face like if the [20:56] documentation is unfair and we report [21:00] those feedback to ensure that we go back [21:03] and make sure the necessary changes [21:10] and one of the major big change that we [21:14] did was about communicating a religious. [21:18] We were shipping features and nobody [21:20] were uh noticing it. [21:23] So [21:26] this was something that we came across. [21:28] So we are building the features. The [21:29] customers would reach out to us and say [21:31] that hey I'm looking for this feature to [21:34] have these features. And our team would [21:36] be like hey we have already built the [21:37] features. Why the people are not [21:39] noticing those things? So if you don't [21:42] communicate those features people are [21:44] not going to notice those things. [21:48] So the first thing we did was if you [21:51] remember earlier in our GitHub issues we [21:54] used to record the customers [21:56] informations. So whenever we start [21:58] working on the feature the first thing [22:00] we did was we informed the customers [22:01] that hey we have started working on the [22:04] features and if there is a expected [22:06] timeline we also communicate those [22:09] things and once the feature is built we [22:12] ensure that we inform the customers that [22:15] hey the feature is built go install the [22:17] update and try that feature and if there [22:20] is any feedback just let us know. [22:24] Now the another thing that most company [22:27] usually do is we started sending out [22:29] newsletter for every major release that [22:32] we have [22:36] and we have a Facebook communicating uh [22:38] community with over 2300 customers and [22:42] this has been a gem for us. Whenever we [22:44] are we release any features we [22:47] communicate to the customers even [22:49] building before building any features we [22:51] build any kind of design or prototype we [22:53] share in the community and they share us [22:56] with the feedback whether they align or [22:58] they align with their goals or not if [23:01] there is any kind of improvement and [23:03] those feedback help us to improve our [23:05] product. So when we are building certain [23:06] things it automatically solves the [23:09] problems that they are looking for. [23:14] So I talked about so many things but [23:17] there are five things I want you to take [23:20] with this meeting with this talk of [23:23] course the first thing if you don't have [23:26] a product team I highly recommend that [23:29] you get uh you build one or there should [23:33] be at least someone in the company who [23:35] owns a why decision why certain features [23:38] is built why you are doing this why not [23:44] restructure your GitHub issues so that [23:46] anyone reading those GitHub issues can [23:48] understand what the issue is, what needs [23:50] to be built, how they can replicate [23:52] those issues [23:55] and define who owns what. Just define uh [23:59] what teams does what and what are those [24:01] uh roles and responsibility. This avoids [24:04] role ambiguity among your team and this [24:06] helps to move things faster [24:10] and use any framework. I suggested to [24:12] you the kano analysis, there are rice, [24:15] there are mosco, any framework that [24:18] helps you to make a quick decision about [24:21] where this features or bug falls under. [24:24] Just use that system or you can build [24:26] your own. [24:29] And last but not the least, make sure [24:32] that whatever you are doing, you are [24:34] communicating with your customers. If [24:35] you're building feature and your [24:36] customers doesn't notice, then I'm not [24:40] sure uh why we are building those [24:42] things. So let's [24:44] communicate every releases build a [24:46] relationship with the customers and [24:50] while doing so we have been so grateful [24:52] that when we started releasing [24:54] communicating those informations [24:56] whenever we are building any features [24:59] and we don't have any clarity we just [25:01] reach out to them hey we are planning on [25:03] building those features let us know [25:05] what's your thought on this one and [25:06] they're very happy to provide the [25:08] detailed feedback or answer the [25:10] questions that we provide and This has [25:12] really helped us to shape how we are [25:14] building our product. [25:17] With that being said, thank you all for [25:19] being here. [25:27] If you have any questions, I'll be happy [25:29] to take [25:39] >> Sure. [25:42] Yes. [25:42] >> I want to ask one question. How I can [25:45] review [25:46] with the AI help. So that [25:50] >> okay [25:51] >> code project is successfully [25:53] because if I have manually verifying a [25:56] code then it can take a time. So how I [25:59] can [25:59] >> okay so here are the things that we are [26:02] doing actually excellent question. So [26:04] manually code review will take time with [26:07] AI being placed. uh you can use the AI [26:09] code editor uh AI uh tools. So in our [26:12] organization we are using claude. So [26:16] even if you don't know what uh how to [26:18] review the code, what you can do is you [26:21] can find for some of the skills or [26:23] WordPress skills like code reviews, it [26:26] will flag some of the mistakes that you [26:27] are doing or some of the basic standards [26:30] of the WordPress. You can use those [26:32] skills to flag those things. But [26:36] ultimately you shouldn't always rely on [26:39] uh the AI for all those things. Just [26:41] like I mentioned the AI will give their [26:43] own logic but the developers has always [26:47] take the final call has to take the [26:48] final call. So use AI as your assistance [26:52] but this will help you to reduce like 80 [26:56] to 90% of the work and then you can go [26:59] through them and then spend 10 to 20% of [27:02] your effort on reviewing it manually. [27:04] the flagged issues. I hope that answered [27:06] your questions. You're welcome. [27:08] >> And one more question. [27:09] >> Yes. [27:09] >> How I can avoid the communication gap [27:11] between teams? [27:14] >> Uh so this is the thing [27:17] uh so it depends on how the team is [27:20] communicating with the team members. So [27:22] the problem that we had in our [27:23] organization was different team members [27:26] had different roles and [27:27] responsibilities. For example, an issue [27:29] gets logged in GitHub. Now who is [27:32] responsible for taking the next action? [27:35] If the role is not clear then people are [27:37] not going to take the actions. Now if [27:40] the developer is working on the features [27:42] there is always an acceptance criteria [27:44] how the features should be built. But if [27:46] the developer is working on the features [27:47] and they don't they came across a [27:50] situations where they are not able to [27:54] like they need certain clarity on how we [27:56] should be building these features. they [27:59] need to reach out to the product team. [28:01] We have defined those things and they [28:03] can do through the Slack channels or any [28:06] other medium. But if it is an on place [28:10] like if you are working together not [28:12] remote just make a quick communications [28:14] or send a slack message. Those are the [28:16] things. Now we need a we build a channel [28:18] like uh one of the thing was use the [28:22] GitHub when everything when somebody tax [28:24] them they get an instant a lot the [28:27] product team gets an information or [28:28] engineering team gets an information so [28:30] this helps us to speed up the things so [28:32] it totally depends on how you structure [28:35] your flow the first thing I would [28:37] recommend is to define the different [28:39] roles and responsibility for each of [28:41] your team members [28:44] you're welcome. [28:49] Yeah. Uh, hello. My name is Nathan from [28:51] Thunder.io. Um, I have a question [28:53] regarding how you would integrate [28:56] support with um the feature requests [28:59] because sometimes, you know, you might [29:02] have customers complaining about an [29:04] issue which could turn into a feature, [29:06] but for what I've seen, it's more of [29:09] something that would integrate with [29:11] GitHub your workflow. But what would be [29:14] a better way to do it? Like if you could [29:18] use some kind of dedicated support tool. [29:22] >> Uh sorry, can you please repeat the [29:24] questions? [29:25] >> Right. But what would be the uh what I [29:26] mean is like what would be the best way [29:28] to integrate the support aspect with the [29:31] the feature requests? [29:34] Uh so in GitHub you can use the tags or [29:38] labels but uh it was very overwhelming [29:41] like we had a lot of backlog so we build [29:43] our own internal systems. [29:44] >> Mhm. [29:45] >> Now there one of the thing that you can [29:48] do is this is something we have been [29:50] doing and I want to share maybe you can [29:52] also take an inspirations. [29:54] >> So whenever customers send a feature [29:56] request there can be two things whether [29:58] it aligns with the product vision or it [30:00] doesn't align with the product vision. [30:01] Mhm. [30:02] >> If it doesn't align, we have partnered [30:04] with the some of the agencies that we [30:07] can refer. Hey, you can refer to those [30:09] agencies and then they reach out. Now, [30:11] if it aligns with your vision, but it's [30:13] not currently being prioritized. Again, [30:15] you have to decide whether you want to [30:17] prioritize or not. If certain features [30:19] they request and maybe not immediate, we [30:22] want to do it. So one thing that we do [30:24] is hey we communicate that these are the [30:27] things which is already in our timeline [30:29] expected is that this one this is the [30:31] thing uh so if you have to log those [30:35] request or the support maybe we started [30:38] with excel sheet trust me we started [30:40] everything gets noted every time the [30:42] excel it would record in the excel sheet [30:44] then the product team would go through [30:46] all the issues that misadventions and [30:48] then we used to work [30:50] >> so my recommendation is to decide how [30:54] you want to structure your flow. [30:56] >> Mhm. [30:56] >> If a feature request get done [31:00] uh how what is the process you define [31:02] the process and based on that you can [31:04] even build your own internal tools or [31:06] decide how it should move from one step [31:08] to another. [31:11] >> All right. [31:18] >> Good morning. [31:19] >> Good morning. Okay. Okay. Sure. [31:22] Uh thank you for the session. Uh my name [31:25] is Himadri. [31:26] >> Uh my question is as a beginner in uh [31:30] production related to WordPress, which [31:33] plat uh which platform do you s uh [31:35] suggest to release your product? Of [31:37] course, other than WordPress.org. [31:40] >> Yes, we release all our products in [31:43] WordPress. I highly recommend in [31:46] releasing your product in WordPress if [31:47] you have the free version [31:50] and uh the best thing about the [31:51] WordPress is the community itself. You [31:54] can always connect if you are building [31:55] any product you can always connect with [31:57] the other team members and ask for the [31:58] feedbacks. The people are going to share [32:00] the feedback. It help you to improve [32:02] your product over the time. So uh one of [32:05] our products is when we build starting [32:07] building the product every product of [32:10] ours is hosted in WP or [32:14] the customer shares the feedback they [32:15] get an exposure from uh using from WP [32:20] repository and then they if they like [32:22] the product and they want more features [32:24] they go to the pro version. So WordPress [32:27] or is the like a gym for distribution. [32:32] So I highly recommend [32:33] >> pro version. Which platform do you [32:35] suggest? [32:35] >> We host on our own websites. [32:38] >> Okay. [32:38] >> For the licensing we use uh there are [32:41] different tools we use is digital [32:43] download. You can even use oocommerce. [32:45] They have also an uh the license [32:48] management feature. Yes. [32:51] >> Okay. Thank you. [32:52] >> You're welcome. [32:55] Yes. Yeah. Uh so my question is like uh [33:00] uh if you are like a product uh owner so [33:04] you can uh make different different [33:07] teams for like product team, engineering [33:09] team so you can decide but when you are [33:12] at the lower level uh like you just join [33:15] the company uh you you yourself [33:18] understand the importance of why we make [33:21] uh different different teams uh but how [33:23] you will convince the upper management [33:27] uh like for these kind of things they [33:29] might have budget restrictions and all. [33:32] So what is your recommendations as a [33:35] like you are at a lower level. So how [33:38] you will recommend an excellent [33:40] question. So uh this depends on how the [33:45] organization works. So for example in [33:48] our organizations the product I'm the [33:51] product owner but I have a product [33:53] associate. The product associate can ask [33:55] me as many questions. They can even [33:57] raise on like raise a questions on my [34:00] thought process. Hey, I'm suggesting [34:03] another way she or he can suggest that [34:05] no, we should be building this features [34:07] like this way. So I have given those [34:09] authority. One of the things that we [34:11] have done is to our engineering team we [34:14] have asked that if you don't agree with [34:16] what the product team has said you just [34:18] let us know. You can ask the questions. [34:21] you need to understand why you are [34:22] building these features instead of just [34:24] building those features. So we have [34:26] given the authority or uh those [34:29] physibility that they can questions [34:31] anything they don't like. So it depends [34:34] on how the structure is done in [34:36] organization or what kind of hierarchy [34:38] is maintained. So we have [34:42] there is a there's a level yes there is [34:44] a positions but we work like as a [34:46] friends as a colleague there isn't like [34:48] seniority hey I cannot raise a questions [34:50] to the product owner [34:52] and it is the responsibility who made [34:54] the decision to convince the person that [34:56] who is making the decision who is asking [34:59] the question sorry [35:01] okay so just talk about maybe once you [35:03] define the roles and uh roles who owns [35:06] what maybe that will help and define the [35:10] boundaries. [35:12] >> Okay. You're welcome. Thank you. Yes. [35:16] >> Yeah. Uh my name is Suraj. Just [35:22] Yeah. So my question is if I'm building [35:24] a WordPress plug-in and let's say I [35:26] published it on WordPress.org, the [35:29] search is terrible. Uh it it doesn't [35:31] match the title at all. And uh if I [35:34] similarly I'm building a react package, [35:36] node package, it exactly matches my [35:39] title and I'll automatically start [35:41] getting users. But that doesn't happen [35:44] on WordPress. So if when you publish a [35:45] new plug-in which is premium, uh how do [35:49] you get the initial users? Do you wait [35:51] for SEO? Do you wait for it to rank on [35:53] WordPress plug-in directory or is there [35:57] a beginner strategy that you follow? [36:00] >> Uh this question is very fast. I think [36:02] that addressing these questions will [36:04] even take an entire session. [36:07] Uh there are different strategies that [36:09] can be uh talked about this one. So one [36:12] of the thing that we did was we already [36:14] have a customer base. So we whenever we [36:17] do any kind of releases we communicate [36:19] those things. But when you are starting [36:21] a new is always a hard thing. Uh so not [36:26] there there are things if you are in a [36:27] certain Facebook communities you can [36:29] share those things. I built those [36:31] things. There are even Facebook groups [36:33] that host like uh promotions Friday or [36:36] something like that where you can go in [36:37] the thread and come like hey I have [36:39] built this product any product not just [36:41] WordPress you can build like the [36:42] different WordPress services or so on [36:45] something to notice join Facebook groups [36:48] they will have certain opportunity maybe [36:50] people are talking about the different [36:52] problems they have if you have a [36:54] solutions or if you have solution just [36:56] know that hey I have the solutions if [36:58] you don't have a solutions you might get [37:00] even a product idea to build on and then [37:02] p him the solutions. [37:04] >> Okay. [37:04] >> Thank you. [37:05] >> Maybe we should connect like I can share [37:07] few things. [37:08] >> Yes. Yes. [37:08] >> Okay. Sure.  📄 **Full text:** ![[Full Document Contents/Articles/WordCamp Asia 2026 Nabin Jaiswal Stop Guessing, Start Building.md|WordCamp Asia 2026: Nabin Jaiswal "Stop Guessing, Start Building" by YouTube]] ## Highlights - and we hire a dedicated product associate whose responsibility was to think about the product all the time. If we are building any features, he or she is responsible to let the team know why we are building this feature. If you don't have any product team, the problem that you'll face is that people will be building the product without knowing why they're actually building those products. So this is the first thing that we did. We ([View Highlight](https://read.readwise.io/read/01kp8j6c1dgrdjc4y9bkf9hg7x)) - Tags: 👻 ai highlighted - differently. In our organizations there are different things that we involve our product team. The first thing they do is analyze the issues. Every week lots of issues get uh recorded in the GitHub and the first thing the product team does is they go through the issues understand the issues and then plan when to build this feature. The next thing is they sit with the engineering and support team to ([View Highlight](https://read.readwise.io/read/01kp8j6c201bgqs25qw6c86h4d)) - Tags: 👻 ai highlighted - understand if anything is unclear. If there is any kind of urgency, the support team communicates to that product team and the product team can escalate with the product owner and then decide when to build those features. The next thing just like I mentions we sit on a a regular basis to analyze what are the different issues that are reported or the feature request why we should be building the feature. If anything is unclear to my product associate I provide the necessary ([View Highlight](https://read.readwise.io/read/01kp8j6c2g8jf32rrzbe7gcfnc)) - Tags: 👻 ai highlighted - waiting for certain time, the things moves faster. And the next thing we did was created a dedicated channel for support and product team. Just like I mentions every week we have lots of issues reported and if we go through let's suppose we have 50 issues reported or feature request or customers pinpoint reported the major the urgent issues get lost. So we created a dedicated channel where the ([View Highlight](https://read.readwise.io/read/01kp8j6c3bd9sfzqj4g8z78j02)) - Tags: 👻 ai highlighted - team analyzes the reported issues, make the necessary research and planning to discuss with the product owner. They also write the acceptance criteria once the uh issue or the feature request is clear and is ready for the development. Now the engineering team implements the feature based on the uh written acceptance criteria. They start the work once everything is clear. So product team help them understand why we are ([View Highlight](https://read.readwise.io/read/01kp8j6c56egd1b4dzwva59c5p)) - Tags: 👻 ai highlighted - that whatever you are doing, you are communicating with your customers. If you're building feature and your customers doesn't notice, then I'm not sure uh why we are building those things. So let's communicate every releases build a relationship with the customers and while doing so we have been so grateful that when we started releasing communicating those informations whenever we are building any features and we don't have any clarity we just ([View Highlight](https://read.readwise.io/read/01kp8j6c98t9rrka8ttg8g56eb)) - Tags: 👻 ai highlighted