Skip to main content

3 min read

Solve your own problems first: Jamie Echlin shares the philosophy and development of ScriptRunner

LS
Lois Shearing
25 October 18 Jira
Solve your own problems first: Jamie Echlin shares the philosophy and development of ScriptRunner
alert2 Icon
PLEASE NOTE
The content of this blog is no longer updated

Solve your own problems first: Jamie Echlin shares the philosophy and development of ScriptRunner

Jamie Echlin discusses his core principles for building great products

We sat down with the creator of ScriptRunner, Jamie Echlin, to chat about the story behind one of the most popular automation apps on the Atlassian marketplace, Jamie shares how he applies his personal philosophy to create products that make an impact.

Build for yourself first

Jamie created ScriptRunner in 2006, while working as a software administrator at a global financial services firm. Its original purpose was to automate some of the more manual and time-consuming aspects of administrating the firm's Jira instance.

At first, he wrote java plugins for different tasks but found that they took too long to write.

"There’s so much you need to learn to write a plugin from scratch. The actual business logic may just be a few lines and the condition might be “You should only be able to approve this if you didn’t create the ticket.” But in reality writing the code could take weeks."

That’s the idea behind ScriptRunner, it lets you focus on the business logic and not the entire boilerplate."

Jamie soon realised that with ScriptRunner, he had created something that not only helped him save time in his own job but could be enhanced and scaled to automate all kinds of functions and workflows across different business workflows.

"My philosophy is; if you’re writing software, you need to make sure it solves a problem for you first. If it doesn’t solve the problem for you, it’s unlikely it will solve a problem for anyone else. But if it does work for you, chances are, you’re not the only person dealing with that problem."

Scale up your capabilities with a team

So how do you take a solution you developed to address your own pain point and turn it into a product that helps others succeed too?

Firstly, Jamie spent years enhancing and expanding ScriptRunner's potential to make sure it really did solve problems for other users. He did this by scouring forums to understand user pain points, he contributed to discussions and answered questions.

"My philosophy is; if you’re writing software, you need to make sure it solves a problem for you first."

Next, he needed a way to make it available to a wider market and acquire resources to develop it further. That's where the Atlassian marketplace and Adaptavist stepped in.

When designing and developing, the ScriptRunner team always start with the customer. They believe in questioning how an enhancement or new release will actually solve a problem.

“We try and bring it back to what basic problem we are trying to solve for the customer. We have an advantage in being able to do this as I’ve sat in the same place as some of our customers, doing the same role, as a business process administrator. I often ask the team, “How is this going to solve a real problem our customers are dealing with every day?"

"We like to spend at least an hour a day talking with the product management team, brainstorming and bringing ideas to life."

 

Jamies coding

Jamie coding at a post-conference meetup

To keep pace with customers the team also do quite a lot of one-to-one interviews with them.

“We see a lot of people writing script fields to show current issues and all of their sub-classed and linked issues and so on. That’s the sort of thing that we then create as a built-in script field so that people don’t have to keep reimplementing the same logic over and over again.”

Let your customers 'kick the tyres' 

The ScriptRunner team also believes in the importance of continuous release cycles and inviting users to try out new features regularly.

“Try to engage with customers and let them try out new features as soon as possible. Let them and give you feedback.”

Otherwise, Jamie believes, teams can end up spending a long time designing a new feature, only to discover when it’s released that it doesn’t solve the problem it needs to.

“Our motivation lies in solving problems, what really gives me and all the developers at Adaptavist a boost, is solving a tricky problem in a creative way.”

 

New to ScriptRunner? How to get started:

Try ScriptRunner for Jira free for 30 days:

Start your free trial

copy_text Icon
Copied!