Teams that I lead create functional, stable, secure, performant, usable, beautiful and delightful products.
Head of Product
Abi Global Health connects patients with doctors in under 30 seconds globally using machine learning, NLP and LLMs to optimise healthcare delivery and predict HCP network availability.
As Head of Product, I was the main product point of contact for our most important enterprise clients. I pitched, prototyped and managed the technical integration of our APIs and embeddable solutions.
Internally, I led the product management, UX design and project management functions, measurably improving the quality of service to our three external stakeholder groups (clients, patients and HCPs).
Founder / CEO
Champion's Mind is a mental skills training platform used by competitive amateur athletes to achieve greater success in sport and life.
The app originated from my interest in continuous improvement and team performance, plus my discovery that there were no good sport psychology training apps available to download.It remains a trusted tool for athletes and coaches worldwide, rating 4.8 (out of 5) in the app store with conversion and retention rates that compare very favorably to leading competitor Headspace (3.8% → 5.8% and 14.9% → 30.3%).
Founder / Director / CTO / CEO
Fluid UI is a SaaS prototyping tool for mobile app designers. As the founding CTO, I built and launched the web and mobile apps, establishing the product as a market leader in the UX design space.
Later, as CEO I drove product vision and execution, designed core features, assembled a high-performing team, closed 2 funding rounds and led the company to profitability.
Fluid UI's success came from deep market insights - mobile app designers needed new tools while incumbent solutions were falling behind due to evolving technology trends (html5, mobile and real time collaborative web applications).
Head of Development
Modeva created premium rate telecoms products for the US, UK, Irish and Australian markets. I led the software, UX, project management and QA teams, bringing multiple new products to market.
My development contributions included coding web and telecoms products, SMPP infrastructure and data analytics tools in HTML/JS, C, PHP and MySQL.
As department head, I transitioned the team from Waterfall to Agile, cut software delivery costs by 30% by securing innovation funding and tax credits, built the team from 2 to 17 and generated over €10M in net new recurring revenue from product launches.
I speak confidently on product, design and development, having received pitch training from the best in San Francisco as well as from professional actors in Ireland.
35m13s
A fascinating discussion about product development, business value and empowering product teams with a growth mindset. Watch on YouTube
14 short segments
Some insightful thoughts about the role of UX design in software development and how it fits into agile development processes. Watch on Vimeo
Just a few of the articles I've written on efficient development, product mangement and UI design
...is hard. This is one way to do it well.
Building exceptional products requires multiple people with diverse skill sets working cohesively to ensure high quality solutions are delivered to a willing market. There must be alignment between marketing, sales, product and technology, with each reinforcing the other to create a single, consistent experience that is delivered to the customer at every stage of their life cycle. Pulling all of those pieces together requires incredible coordination, doubly so when the communication structures and processes aren’t a good match for the needs of the company at a given moment in time.
In writing this, I have deliberately stuck to a prescriptive writing style, while recognising that my actual approach is better summarised as “strong beliefs, loosely held”. Every company is unique. Every process should be adapted to the specific needs of that company. Processes that fail to add value should be eliminated. Processes that don’t make sense, or which are overly complex or have reporting requirements that don’t impact business outcomes should be streamlined. A team should feel empowered to own their own processes, but shouldn’t be allowed to change them without first executing the process as it is currently written.
A successful process is not a document that an external consultant prescribes to a team. Rather, it should be the codification of best practice agreed and maintained by the team itself. Every process should be defined, owned, measured, reviewed and self-improving. Repetition breeds efficiency, and the first version of any process takes time to bed down. Sticking with it and having scheduled times for self-reflection are how processes become ingrained and ultimately leads to meaningful efficiency and quality gains.
Creating new processes should only come after careful consideration. Companies have a tendency to want to introduce new processes as a result of individual human error. Rather, this is an educational opportunity which should not, at least on first occurrence, be seen as a reason to codify a more complicated set of behaviours that will impact the overall functioning of the company.
Once a process is adopted, it naturally atrophies over time and must be policed by the process owner to ensure that standards are maintained. This is best done by ensuring that the process itself is reviewed and improved as an intrinsic part of its execution. Leadership should also continuously reinforce how the efficiency of the process created by the team plays a major role in the successful outcomes that are being delivered.
Finally, processes themselves are often viewed in a negative light. This only arises when the value of the process itself is poorly understood or has been prescribed from the outside, eliminating the sense of ownership and pride that the team has in the quality of work that it delivers.
Hopefully it is clear that I favour light touch, self-managed processes that improve the efficiency of frequently recurring tasks. Each process has a maintenance overhead. By having a small number of team-owned processes, the company becomes capable of delivering predictably while also maintaining a flexible problem solving mindset which can quickly adapt to changing business circumstances.
What follows is a cohesive set of product, project and software development processes that have brought value to the teams I've worked with over the last 20 years. It is structured broadly as follows, starting with product management.
The goal of product management is to make sure the right product is built the right way. This can be achieved with three core activities: discovery, prioritisation and delivery.
Discovery is a workman's toolbox of techniques for understanding client pain points. It should mix quantitative and qualitative approaches such as data analysis, user interviews, contextual analysis, prototyping, market research and competitor analysis. Qualitative techniques reveal what could be improved while quantitative techniques reveal by how much. Discovery outputs are recorded in the product roadmap and issues backlog which are reprioritised continuously.
Prioritisation compares costs and benefits to create a sequential plan that maximises company growth (or other company defined objective).
Techniques like MosCoW and RICE can be used, though at early stages I prefer to prioritise directly from quarterly objectives such as OKRs where possible. Projects which are not deemed valuable, viable and feasible should also be pruned at this stage.
If the company's brand claims it wants to be known for something specific (e.g. accuracy or usability) then that needs to be disproportionately prioritised.
It is impractical to extensively plan a product roadmap beyond a time horizon where the company can reasonably predict an unchanging set of business priorities. Rather, the team and executive leadership should champion the team’s agility and capacity to change direction quickly without incurring wasted planning time.
Once the roadmap is prioritised, the goal becomes to deliver projects as efficiently as possible. There is always an optimal number of projects in the production pipeline and there is always a bottleneck in one or more areas of expertise.
The value of a project is realised after it is finished, not when it is started. Thus the focus should always be on finishing projects before starting new ones. Too many concurrent projects negatively impacts the rate at which business value is created. Having 100 ways to nicely say no is a product management superpower.
Gantt or Kanban work in progress limits can be used to ensure projects only enter the production pipeline once the required resources are known to be coming free.
Product roadmaps are broken down into projects in order to deliver to market faster and to constrain the cognitive load involved in developing complex software products. Project scope should always be kept to a minimum. Increasing a project's scope does not result in developers achieving more with the same time, but it does impact the frequency at which business value is created and creates additional risks that the project will not be delivered successfully.
Agile is a philosophy. It espouses the frequent delivery of well designed software by self-organising teams who prioritise face to face communication and a sustainable development cadence. It recognises that new requirements can arise at any time and that the ability to change direction quickly should be welcomed as a competitive business advantage. It suggests that developers and business people work together daily in cross-functional team structures. Originally written in 2001, modern interpretations now include design as a primary stakeholder too.
Kanban and Scrum are methodologies. Both work. Kanban allows for easier visualisation of bottlenecks and resource utilisation across the entire production pipeline and can deliver higher quality outcomes.
Scrum offers a more predictable release cadence and is easier to manage using regularly scheduled meetings.
When teams are self-managed and outcome focused, I prefer Kanban. When management is top down and feature focused, Scrum may be a better choice. Various iterations of "Scrumban" try to achieve the best of both worlds. Teams that have hard client deadlines should also consider Gantt planning to better predict resource availability and provide more accurate timelines.
Just like you wouldn't hammer in a screw or drill in a nail, different types of software development work requires different tools.
Close attention should always be paid to the amount of time reactive work takes as this unplanned work, when it happens, inevitably impacts on the delivery of project and recurring work.
Software project management involves 5 core activities: requirements definition, design, development, testing and deployment. Bugs in deployed software are maintained via an issue tracking process. Projects may end after deployment or there may be an additional reporting phase to measure whether it has achieved its stated goals. Project outcomes should always be communicated back to the project team.
Projects slip day by day, not all at the end. They can only be brought back on track if lost time is recognised immediately. Reducing scope, extending timelines, adding resources and working overtime can all get projects back on track (though adding resources rarely succeeds and excessive overtime causes burnout). All projects should have a contingency budget built in (start with 20% and adjust as needed).
If a team starts to run over frequently, a culture of non-delivery may begin to creep in. To combat this, choose a smaller scope that can definitely be delivered within a project or sprint timeframe and reset the team's expectations so that they achieve project / sprint goals as part of their culture.
Product teams should be self-contained organisational units which control all of the necessary resources to deliver their assigned outcomes. If external dependencies are unavoidable, resolving them should always be the first priority in a project.
If a project's feasibility is unknown, the project should be split and its feasibility established before committing resources to the rest of the project. The project manager should ensure that enough resources are reserved shortly after project completion to handle any bugs or issues that arise with live usage. Closest attention should be paid to the critical path, which, if delayed, will result in the entire project being delayed.
The objective of writing requirements is to communicate a specific set of changes to a product’s functionality. They should be written as explicit, verifiable statements by the most applicable subject matter expert for the milestone being developed. They are a tool to support the development of working software, where working software remains the actual measure of success. Developers must input into requirements to make sure they meet their expectations as part of the development process.
Requirements should cover only the specific functionality needed for a release. An "out of scope" section can help communicate which ideas have been moved to a future iteration. Requirements are complementary to development standards, which cover the regular expectations that the development team should adhere to in every release (e.g. coding standards, server response times and UI component frameworks).
There is no such thing as a final design or requirements. Modern software is continually improving. A “minimal viable” mindset means moving forward without perfect information at times. For hard deadlines, developers should be protected from late changes in requirements. At other times, the team should be aligned around continuous learning and delivering successful outcomes rather than mechanically sticking to immutable requirements definitions.
Like software, requirements can have errors (bugs) and require iterations. This should not prevent projects from progressing to the coding phase. Requirements should also be fed to the QA for test case creation and copywriters (or the project manager) to update product documentation as needed.
Designers work at two levels - the product level and the project level. At product level, they need time to explore the visual identity and UI design patterns that will feed into creating a holistic product experience. This work is taken from the entire product roadmap and helps communicate the overall vision for the product as well as generating many powerful sales and marketing assets.
At a project level, designers should interact daily with front-end developers to answer their questions and test usability. Development versions of software should be made available early and often to designers. These daily developer microinteractions quickly compound, turning mediocre products into highly desirable solutions.
Stakeholder feedback is required at every stage of the design process, though that feedback should focus on communicating customer needs and business constraints while avoiding directly inputting into how the UI should work (that being the remit of the UI or UX design expert that has been hired to do that job). High fidelity screenflows and prototypes are the most effective ways to communicate product concepts.
Design standards should be applied to every aspect of the company, not just at the product level. UI design standards, branding guidelines and accessibility considerations should paint a single, coherent brand experience regardless of whether someone is in your product, on your website, looking at an ad or even applying for a job. Companies that do this correctly grow significantly faster than their peers.
Development involves writing code, committing it to a repository and once reviewed, deploying it to a customer facing environment ("live"). Everything discussed so far is a support function for this practice.
Every software development effort should have at minimum two environments in which a product can be accessed - a test environment and a live environment. Both should be identically configured but operate entirely separately. Once code is validated in the test environment, it can be moved to live. Developers must test their own code, but a second brain review should be completed before pushing to live.
Developers may also require a development environment (often running locally on their computer) and a staging environment. A local environment allows for faster development, and a staging environment allows for final testing in the live environment (using live customer data).
Software is good enough to go live if it is an improvement on the existing live version. Going live should never have a big bang moment. Deployment should be a frequent and heavily automated process. Regressions discovered as part of testing for a release must be fixed immediately. Regressions discovered in live software follow the issue tracking process. Don’t go live on Friday afternoon unless you like work phone calls over the weekend.
Software versioning typically uses the “Major.Minor.Patch (build number)” notation, e.g. version 1.0.1 (312). This should be consistent not just within the development team, but also used in public facing documentation such as APIs, release notes and marketing efforts.
An opportunity to manage technical debt can be provided at the start of each project (or sprint) and included in the requirements specification and project estimates. The scope for this should be limited to code impacted by the project. Larger architectural changes should be managed as projects in their own right. In this case, the scope of the project should be limited achieving functional parity with the existing live product first.
I prioritise issues on a scale of P1-P4 according to the severity and impact of the issue. Many teams prefer to use low/medium/high tags. Personally I've found that a slightly more abstract framework leads to greater rationality in prioritisation discussions.
The internet is awash with malicious, automated bots trying to access websites, checking for open ports and looking to exploit unpatched vulnerabilities on servers. These automated scripts, if allowed to get access to systems can easily generate massive server bills, copy and/or delete all customer data and steal IP. Denial of service attacks can take your servers out of action without being breached, again generating massive bills and leading to requests for payment in order to stop.
Combating all of these attacks is a race to maintain layers of protection against ever evolving attack vectors. Protections include upgrading software versions, continuous monitoring for breaches and in the worst case scenario, having backups and failover sites ready to go. Special attention should be given to generic tools embedded in your software (e.g. Captcha forms, Wordpress login pages) as there is a greater incentive to create automated attacks for these given their prevalence on the internet.
Daily backups are easy to configure with most cloud providers. Access to the production environment should be the most secure information in your company. Security should be prioritised behind stability and ahead of performance and usability on the product roadmap. Enterprise clients also frequently require SLAs in terms of uptime so there may be additional consequences for outages and lost data.
The role of a tester is to make sure that software works as documented. The role of quality assurance is to ensure that the company continually gathers all feedback about product quality and improves the standards it has established in every aspect of what it produces. No points for guessing which I think adds more value.
QA engineers should lead testing and also make themselves available to help replicate and document issues that are found by other members of the organisation including sales, support, design and other developers. They should be empowered to openly search for and categorise bugs using customer support inquiries and metrics in both test and live environments. Bug-0 and 0-regression releases are their goals.
I define a bug as functionality that does not match documented, intended behaviour. Software will always have bugs. Prototypes and requirements definitions can have them too. The technical definition of whether something should be defined as a bug or anything else is not overly consequential and is a lost opportunity to focus on what the customer really cares about.
Not every bug needs to be fixed immediately. The decision to prioritise bugs, issues, usability improvements, performance enhancements and new projects is a business decision.
Test automation should appear on the roadmap once the core product design has stopped changing frequently. Test coverage can be developed in parallel with releases, or priorised separately based on feature usage or other metrics.
The "minimum viable team" when founding a startup is often expressed as the trio of “Hustler, Hacker and Hipster” (business, tech and design). This trio encompasses the necessary skillsets and team structure of an early stage startup. As the company grows and succeeds, it can choose to structure itself functionally or cross-functionally.
Functional teams drive higher standards in functional areas (design, coding, marketing etc) but communication between diverse areas of expertise is more difficult leading to less creative problem solving and slower delivery of cross-functional projects.
Cross-functional teams are self contained units containing all of the resources needed to solve their assigned tasks. They get more done with fewer communication issues, but suffer from greater difficulty establishing company wide functional standards (e.g. design or coding standards). Establish your desired ratio of product managers / product owners, designers, developers, testers. I would aim for about 1:1:6:1.
Matrix and spiral organisational structures make an effort to merge the benefits of both approachs but are harder to make work. The product team should be scaled in accordance with the desired software architecture (corollary of Conway's Law). Keep a strong eye open for copy-paste type work, where data is being duplicated between teams because of a lack of coordination or agreed tool usage. This busy work can be eliminated with better coordination and adds no value. Project management, design and product management are frequently co-located in scaling companies as their services are all cross-functional in nature.
If a team is responsible for outcomes (measured business value creation), then they must be empowered to choose how they solve their tasks. If they are responsible for outputs (feature delivery), delivering the feature is the success criteria. Actual usage or business value does not belong to the team.
Metrics, levers and gatekeeping processes allow the management team to confidently delegate decisions to product teams without implementing excessive levels of overhead. Levers allow teams to work without escalation as long as the work falls within the defined but adjustable boundaries. Escalation occurs if a metric falls outside of a defined target (e.g. conversion rates drop or a project is running above budget). Gatekeeping processes represent the key touchpoints which require management signoff on before committing additional resources to achieving an objective.
Have you ready all the way down?
Really?
Amazing.
I am highly grateful for your time.
While the information presented above may be highly condensed, it remains just a brief outline of what it takes to efficiently deliver delightful products to a willing customer base.
Every statement I've made has a hard learned lesson behind it. I would be absolutely delighted to discuss any of these processes over a coffee or a pint with no motivation other than to continue to learn from others who are following a similar or tangential path to my own.
Alternatively, if you think I could add value in your company, I'd love to chat too.
Shoot me a WhatsApp or an email at dave@dkearney.com. I'll be back on to you as soon as I can.
I'm Dave. I live in Blackrock, County Dublin, with my wife, 2 kids and no dog.
I do my best to stay reasonably fit (though I have an incredibly sweet tooth). I've been a Leinster Rugby season ticket holder for ~15 years. I enjoy gaming more than Netflix (unless it happens to be a physics documentary).
At home, you'll probably catch me relaxing with a nice whiskey and music that would scare the living bejaysus out of your grandmother.
I care deeply about using technology to move the human race forward, with entrepreneurship as a conduit to achieving that.
I've spoken on software design, development and product management topics in San Francisco, at Dublin UX, in Dogpatch Labs and in Dublin Business School.
In 2025, I am looking forward mentoring student entrepreneur teams from my alma mater Trinity College for the first time.
I've also contracted with Dogpatch Labs to help provide their corporate innovation programs for the likes of Ulster Bank and Electric Ireland in the past.